Data transmission

ABSTRACT

A data communication system for communicating one or more payload streamed data signals and an auxiliary data signal, said auxiliary data signal being organised as one or more data packets according to a data packet protocol, each packet having a packet destination address, comprises: at least two data handling nodes, a transmitting one of said data handling nodes being arranged to transmit data to a receiving one of said data handling nodes; a transmission data formatter associated with said transmitting node for formatting said packets of said auxiliary data signal into a streamed data signal format and for multiplexing said payload streamed data signals and said formatted auxiliary data signal into a bitstream for transmission; a received data reformatter associated with said receiving node for demultiplexing said input streamed data signals and said formatted auxiliary data signal and for reformatting said auxiliary data signal into packets according to said data packet protocol.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to data transmission.

2. Description of the Prior Art

Direct Stream Digital (DSD) is a high-resolution single-bit audio codingsystem used for the so-called Super Audio CD consumer disc format. DSDwas developed with a view to producing audio signals comparable to thosereproduced from the best analogue formats. DSD signals can produce afrequency response from DC to 100 kHz and have a dynamic range ofgreater than 120 dB across the audio band.

DSD makes use of 1-bit digital audio and requires a high frequency audiosample clock at 64 Fs=2.8224 MHz (the sample clock of standard PCMsystems (Fs) is 44.1 kHz). This high frequency sample clock istransmitted along with the data to facilitate accurate signalreconstruction at the receiving end. Furthermore each channel of 64 FsDSD audio requires a transmission bandwidth of 2.8224 Mbit/s.

Several known audio networking systems make use of Ethernet to transmithigh bandwidth audio-data between a network of audio processing devices.For example the “Magic” system proprietary to Gibson makes use of theEthernet Media Access Control MAC layer (i.e. physical layer and datalink layer) to transmit audio data at a fixed audio sampling frequencyof 48 kHz using one Ethernet frame per sample period. The CobraNet audionetworking system proprietary to Peak Audio also uses the Ethernet MAClayer to transmit uncompressed digital audio data between networkeddevices. The CobraNet system uses a 48 kHz sampling rate and allows fortransmission of 20-bit and 24-bit audio data. However, none of theseknown systems provides an interconnection suitable for linking DSD audiodevices. This is because Ethernet frame timing is completely unsuitablefor transmitting a 2.8224 MHz DSD sample clock.

Copending application Ser. Nos. 10/620,671 and 10/803,621 relate totechniques for carrying such bitstreams over the physical layer of anEthernet-type interface. The systems described in these two copendingapplications aim to provide circuit-switched interconnections betweenlarge-scale multi-track production equipment for DSD audio such asmulti-channel ADC/DACs, DSD mixers and multi-channel DSD recorders.

So, in the systems of the two copending applications techniques areprovided which are based on the direct use of the Ethernet physicallayer interface. This can be shown to provide effective and low-latencycircuit-switched links at audio data rates of the order of 64 Fs, suchsystems also being useful for the transmission of other streamed digitalsignals such as PCM audio signals. Auxiliary data channels can also behandled by the same means. However, as this is achieved by deliberatelyavoiding the use of higher levels of the Ethernet protocol, there is noconvenient way of providing packet-switched auxiliary data routingwithin such a system.

SUMMARY OF THE INVENTION

This invention provides a data communication system for communicatingone or more payload streamed data signals and an auxiliary data signal,the auxiliary data signal being organised as one or more data packetsaccording to a data packet protocol, each packet having a respectivepacket destination address, the system comprising:

-   -   (i) at least two data handling nodes, a transmitting one of said        data handling nodes being arranged to transmit data to a        receiving one of said data handling nodes across a data        connection link;    -   (ii) a transmission data formatter associated with said        transmitting node for formatting said data packets of said        auxiliary data signal into a streamed data signal format and for        multiplexing said payload streamed data signals and said        formatted auxiliary data signal into a bitstream for        transmission;    -   (iii) a received data reformatter associated with said receiving        node for demultiplexing said input streamed data signals and        said formatted auxiliary data signal and for reformatting said        auxiliary data signal into packets according to said data packet        protocol.

This invention also provides a data router arranged to receive a datastream containing data packets, having associated destinationindicators, via two or more input/output channels and to direct eachpacket to one or more input/output channels in dependence on saidrespective destination indicator, in which each input/output channel hasan associated maximum data rate, said router comprising:

-   -   an Ethernet router; and a routing interface associated with each        input/output channel; said routing interface and said Ethernet        router being operable to communicate at a data rate higher than        said maximum data rate associated with at least some of said        individual input/output channels;    -   said routing interface being arranged to supply data packets        received via said data stream associated with that input/output        channel to said Ethernet router in said form of Ethernet data        packets;    -   said routing interface being arranged to receive data packets to        be output via said corresponding input/output channel from said        Ethernet router and to provide said data packets as a data        stream for output by that channel at a data rate no greater than        said channel's maximum data rate; and    -   said routing interface and said Ethernet router co-operating to        selectively inhibit said transfer of data packets from said        Ethernet router to said routing interface in order to avoid        exceeding that channel's maximum data rate.

Further respective aspects and features of the invention are defined inthe appended claims.

The invention addresses the above problems by embedding packetisedauxiliary data into the streamed payload signal, and then on receptiondemultiplexing the packets into a format suitable for routing using astandard (e.g. Ethernet) router.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages of the inventionwill be apparent from the following detailed description of theillustrative embodiments which is to be read in connection with theaccompanying drawings, in which:

FIG. 1 shows the standard seven-layer Open Systems Interconnection (OSI)model for network protocol architectures and sub-layers of the Ethernetphysical layer;

FIG. 2 illustrates a known system for signal transfer in DSD systems;

FIG. 3 schematically illustrates a DSD interconnection according to anembodiment of the present invention;

FIG. 4 illustrates a star-configuration interconnection that can beformed between several individual items of DSD equipment;

FIG. 5 schematically illustrates an audio data transmission systemaccording to an embodiment of the present invention;

FIG. 6 schematically illustrates how the 64 F_(s) audio sample clocksignal is transmitted in parallel with the DSD audio data alongdifferent signal pairs of the category 5 cable;

FIG. 7 schematically illustrates reception of the high frequency audiosample clock in parallel with reception of the DSD audio data signal;

FIG. 8 schematically illustrates the signal path of the 64 Fs DSD sampleclock signal;

FIG. 9 depicts an embodiment of the invention in which thesynchronisation of the physical layer device is adjusted such that it isan exact multiple of the audio sample clock frequency;

FIG. 10 schematically illustrates a point-to-point audio device link inwhich one device acts as a clock master whilst the other device acts asa clock slave;

FIG. 11 is a flow chart which illustrates the sequence of eventsfollowed to establish a synchronised link between the master device andthe slave device of FIG. 8;

FIG. 12 schematically illustrates an apparatus in which multipleparallel links are used between two pieces of audio equipment in orderto achieve a higher channel count than that achievable via a singlepoint-to-point link;

FIG. 13 is a flow chart illustrating how the local clock signalsF_(s)(A) and F_(s)(B) are employed to ensure that the outputs of tworeceivers are kept synchronous;

FIG. 14 schematically illustrates how audio data buffering is performedin the transmitter;

FIG. 15 schematically illustrates how audio data buffering is performedat the receiver;

FIG. 16 schematically illustrates the data structure corresponding to astandard Ethernet frame;

FIG. 17 shows the structure of an audio data frame according to anembodiment of the present invention;

FIG. 18A shows the audio data frame format arranged as 384*4-byte datawords;

FIG. 18B schematically illustrates a 24 DSD channel frame format inwhich each frame comprises 368 data words including 352 DSD samples for24 channels plus 88 bytes of auxiliary data;

FIG. 19 shows the control data format arranged as 26*4-byte data words;

FIG. 20 schematically illustrates the structure of each of the three16-bit frame format field sections corresponding to the frame format ofFIG. 18B;

FIG. 21 schematically illustrates the three 4-nibble sections of theframe format ID containing a set of data entries to be processed at thereceiver;

FIG. 22 schematically illustrates the format of the 32-bit data blockcorresponding to the 24 DSD channel frame format of FIG. 18B;

FIG. 23A schematically illustrates how six parity bits P0 to P5 aregenerated from 24 audio data bits and the two auxiliary data bits;

FIG. 23B schematically illustrates how a syndrome is calculated byperforming XNOR operations on the received data elements;

FIG. 24 is a table showing a the composition of a stream of nibbles fromthe interleaver for the 24 DSD channel frame format of FIG. 18B;

FIG. 25 schematically illustrates the protocol layers of the MAC-DSDprotocol for the particular example embodiment using the 24 DSD channelframe format;

FIG. 26A schematically illustrates the AES3 sub-frame format;

FIG. 26B schematically illustrates the sub-frame format for PCMtransmission according to the present technique;

FIGS. 27A to D schematically illustrate how three different indicationsS, Z and V are

-   -   multiplexed using the M-bit of FIG. 26B;

FIGS. 28A to E schematically illustrates circumstances in which theS-bit takes precedence over the Z-bit in the M-bit of the sub-frameformat according to FIG. 26B;

FIG. 29 is a table 10 defining a frame type value index for a each of anumber of different frame formats including frame types having differentnumbers of PCM samples per frame;

FIG. 30 is a table specifying the information derivable from the flagbits of the frame format of FIG. 18B;

FIG. 31 specifies how values for the two flag bits associated with thebase clock are interpreted;

FIG. 32 schematically illustrates how a multiplexed clock signal isformed in dependence upon a 64 Fs signal and a word clock signal;

FIG. 33 schematically illustrates five consecutive DSD samples and theirtiming relationship with the local 64 Fs clock and the word clock;

FIG. 34 schematically illustrates a MAC DSD transmitter adapted fortransmission of both PCM and DSD data;

FIG. 35 schematically illustrates a MAC DSD receiver adapted forreception of both PCM and DSD data;

FIG. 36 schematically illustrates a system in which twosample-synchronous links are operated in parallel and in which the Fs/nsync is used to synchronise the parallel links;

FIG. 37 schematically illustrates a measured difference in propagationdelay between the two parallel links of FIG. 27;

FIG. 38 is a schematic diagram showing auxiliary data routing by aMAC-DSD router;

FIG. 39 is a schematic diagram showing a protocol by which auxiliarydata is carried;

FIG. 40 schematically illustrates a data structure of an auxiliary dataframe;

FIGS. 41 and 42 schematically illustrate the operation of an auxiliarydata router in a data receive mode and a data send mode respectively;

FIGS. 43 and 44 schematically illustrates a data scrambler and acomplementary descrambler respectively;

FIG. 45 schematically illustrates the generation of a carriersense/receive data valid signal; and

FIG. 46 is a schematic state diagram illustrating the use of an RMIIlock function.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

As described above, some known audio networking systems use the datalink layer of Ethernet for transmission of uncompressed digital audiodata at standard sampling frequencies of around 48 kHz. By way ofcontrast, embodiments of the present invention use the physical layer ofFast Ethernet to provide a point to point connection for transmission ofhigh frequency (2.8224 MHz) digital audio data. The advantages of usingthe physical layer of Fast Ethernet for audio data transmission are thatit offers a large bandwidth, has proven electromagnetic compatibilityand has error detection functionality (cyclic redundancy checks) alreadyin place. Use of the physical layer makes the logic easy to design andimplement. There is no need to be concerned with hardware addressing andimplementation of windowing protocols as would likely be required if theaudio data were encoded using higher layer (e.g. MAC layer) technology.Furthermore at the physical layer level, Ethernet data transmission isrobust and spectrum controlled so that electromagnetic emissions arelow.

In order to explain the principles by which the present embodimentsoperate, the layered structure of network protocol architectures and thelower layers of the Ethernet architecture will be described in detailbelow.

FIG. 1 shows the standard seven-layer Open Systems Interconnection (OSI)model for network protocol architectures. The model comprises anapplication layer 270, a presentation layer 260, a session layer 250, atransport layer 240, a network layer 230, a data link layer 220, and aphysical layer 210.

The application layer 270 provides a user interface, usually in the formof an application program, to a range of distributed informationservices on the network. The services provided by this layer includefile transfer, access and management, as well as general document andmessage interchange services such as electronic mail.

The presentation layer 260 is concerned with the representation of dataduring transfer between two communicating application processes. Itselects an appropriate transfer syntax to be used during a transaction,so that the structure of the messages being exchanged between twoapplication entities is maintained. The presentation layer 260 alsomanages data encryption and data compression.

The session layer 250 establishes sessions between communicatingapplications on communicating network nodes. It may optionally provideinteraction management during two-way alternate i.e. half-duplex (ratherthan two-way simultaneous i.e. full-duplex) data exchange. Furtheroptional features provided by this layer are synchronisation for lengthynetwork transactions and exception reporting.

The transport layer 240 acts as an interface between the higherapplication-oriented layers (session 250, presentation 260 andapplication 270 layers) and the underlying network-dependent protocollayers 210, 220, 230. The transport layer provides the session layerwith a defined set of message transfer facilities. It offers a number ofclasses of services appropriate to different types of network, rangingfrom class 0 which provides basic connection establishment to class 4which provides full error control and flow control.

The lowest three layers (network 230, data link 220 and physical layers210) of the OSI model are all network dependent. The network layer 230is responsible for establishing and clearing a connection between twotransport layer protocol entities and it supports network routing andaddressing. The data link layer 220 provides the network layer with areliable information transfer facility and is responsible for suchfunctions as error detection and message retransmission. Typically botha connectionless and a connection-oriented service is provided. Theconnectionless service simply discards received frames in which an erroris detected whereas a connection-oriented service aims to provide anerror-free information transfer facility. Finally, the physical layer210 provides the data link layer 220 with a means of transmitting aserial bit stream between two pieces of equipment. It converts the datainto the stream of electric or analogue pulses that will actually crossthe transmission medium and it oversees the transmission of data.

Ethernet is a local area network (LAN) technology, which uses a simpleor branching bus-like connection line. The transmission medium in anEthernet network is formed from one or more continuous lines of cablelinked by hubs. Network devices are connected to the cable and theycompete for network access using a Carrier Sensing Multiple Access withCollision Detection (CSMA/CD) protocol. According to the CSMA/CDprotocol, all client devices monitor the transmission medium and waituntil the transmission line is available before transmitting anymessages. If two network nodes try to transmit messages at the sametime, a collision occurs. The client devices then stop, wait for arandom time interval and attempt to transmit again.

Standard Ethernet systems known as 10BASE-T systems provide transmissionspeeds up to 10 Mega bits per second (Mbps) whereas so-called “FastEthernet” (or 100BASE-T) systems provide transmission speeds of up to100 Mbps. Further higher performance systems are available such asso-called “Gigabit Ethernet”. Fast Ethernet uses the same wiringsystems, Media Access Control (MAC) method and frame methods as 10BASE-TEthernet. The embodiments may use any of these systems.

Ethernet systems may use twisted pair cabling or an optical fibreconnection. Twisted pair is standard copper wire that is typically usedto connect computers to a telephone link. To reduce cross-talk orelectromagnetic induction between pairs of wires, two or more insulatedwires are twisted around each other. The twisting reduces the effectiveradiating area of the cable because electromagnetic effects of alternatetwists tend to cancel at distances greater than the twist pitch. Eachconnection on twisted pair requires two wires. If the twisted pair isenclosed by a shield that functions as a ground it is known as shieldedtwisted pair (STP). Standard twisted pair cabling is known as unshieldedtwisted pair (UTP).

In Fast Ethernet systems the segment length for twisted pair cablesegments is set to a maximum of 100 m to ensure that signal round-triptiming specifications are met. The problem with Fast Ethernet is how toachieve a data transfer rate of 100 Mbit/s over unshielded twisted-paircable (UTP). In practice there are two standards that can be used toachieve this, one of which (100BASE-4T) uses voice-grade category 3cable and another (100BASE-X) which uses either high-quality category 5UTP cable, shielded twisted-pair cable (100BASE-TX) or optical fibre(100BASE-FX). In the 100BASE-X system each type of transmission mediumrequires a different Physical Medium Dependent (PMD) sublayer. Category5 UTP comprises 4 signal pairs, two pairs of which are typicallyutilised for Ethernet i.e. one signal pair for clock transmit andreceive and one signal pair for data transmit and receive. This leavestwo unused signal pairs.

The sub-layers of the Ethernet physical layer and data link layer areshown alongside the seven layer OSI model.

The data link layer 220 comprises the Media Access Control (MAC) layer224 and the Logical Link Control (LLC) layer 222. The physical layercomprises a reconciliation sub-layer 219, a Media Independent Interface(MII) 218, a physical coding sub-layer 216, a physical medium attachmentsub-layer 214, a physical medium dependent sub-layer 212 and a MediumDependent Interface (MDI) 211.

The MAC sub-layer 224 performs the two main functions of dataencapsulation and media access management. The data encapsulationfunctionality includes data framing, handling of source and destinationaddresses and detection of physical medium transmission errors. Themedium access management functionality includes medium allocation(collision avoidance) and contention resolution (collision handling).

The MAC sub-layer 224 can operate either in half-duplex mode or in fullduplex mode. In half-duplex mode, network nodes contend for use of thephysical medium using multiple access (CSMA/CD) algorithms. The fullduplex mode allows for simultaneous transmission and reception withoutinterference. For the full duplex mode to be used three conditions mustfirst be satisfied. Firstly, the physical medium must be capable ofsupporting simultaneous transmission and reception without interference.Secondly there must be exactly two nodes on the local area network sothat the physical medium is treated as a full duplex point-to-point linkbetween the nodes. The use of CSMA/CD algorithms is unnecessary in thisfull duplex case because there is no contention for use of a sharedmedium. The third condition is that both network nodes must beconfigured to use full duplex operation.

The Logical Link Control (LLC) layer 222 performs error-checkingfunctions on data frames and manages links between communicating networknodes.

The Reconciliation 219 sublayer maps the signal set provided at theMedia Independent Interface 218 to the Physical Coding Sublayer 216.

The Physical Coding Sub-layer (PCS) 216 provides a uniform interface tothe Reconciliation sub-layer for all 100BASE-TX physical layer entity(PHY) implementations. The PCS 216 provides all services required by theMII including: encoding of MII 4-bit “data nibbles” to 5-bit code groups(and also decoding from 5-bit to data nibbles); generation of carriersense and collision detect indications; serialisation of code-groups fortransmission on the underlying PMA sub-layer 214 (and de-serialisationof code groups on reception from the PMA 214); and mapping of transmit,receive, carrier sense and collision detection between the MII 218 andthe underlying PMA 214.

The Physical Medium Attachment (PMA) sub-layer 214 provides amedium-independent means for the PCS to support the use of a range ofphysical media. The 100BASE-TX PMA performs the functions of: mapping oftransmit and receive code-bits between the underlying Physical MediumDependent (PMD) sub-layer 212 and the PCS 216; and generating a controlsignal indicating the availability of the PMD 212 to a PCS 216. The PMAsub-layer 214 may optionally: generate indications of carrier errorsfrom the underlying PMD sub-layer 212; sense receive channel failures;and transmit far-end fault indications.

The PMD sub-layer 212 is effectively a set of signalling standards thatdefine 125 Mbit/s full duplex signalling systems, which accommodatemulti-mode optical fibre (F), shielded twisted pair (STP) and unshieldedtwisted pair (UTP) wiring.

The purpose of the Media Independent Interface (MII) 218 is to provide asimple interconnection between the MAC sub-layers 222, 224 and thephysical layer entities (PHYs) for data transfer at 10 Mbit/s and 100Mbit/s. The functionality is identical at both data rates, as are thesignal timing relationships. The only difference between 10 Mbit/s and100 Mbit/s operation is the nominal clock frequency. The MII 218 is usedto provide media independence for various forms of unshieldedtwisted-pair wiring, shielded twisted-pair wiring, fibre optic cablingand potentially other media, so that identical MACs may be used with anyof these media. The MII 218 maximises media independence by cleanlyseparating the Data Link Layer 220 and the Physical Layer 210 of the OSIseven-layer reference model. The data and delimiters of the MII 218 aresynchronous to clock references and the MII uses Low VoltageTransistor-Transistor Logic (LVTTL) signal levels compatible with commonintegrated circuit processes. The MII 218 provides independent 4-bitwide data-transmit and data-receive paths and full duplex operation.Each direction of data transfer is serviced with 7 signals: a 4-bit databundle, a 1-bit delimiter signal, a 1-bit error signal and a 1-bit clocksignal.

FIG. 2 illustrates a known system for signal transfer in Direct StreamDigital systems. The apparatus 300 comprises ananalogue-to-digital/digital-to-analogue (ADC/DAC) converter 310connected to a DSD multi-channel recorder 320. The connection comprisestwo separate cables: a first cable 315 is an optical fibre carrying 8channels (about 22.6 Mbit/s) of DSD audio data and a second cable 325carries the high frequency sample clock. It is standard studio practiceto use separate cables for the audio data and the sample clock.

FIG. 3 schematically illustrates a DSD interconnection according to anembodiment of the present invention. In this arrangement 400, a singlecable 405 is used to connect a multi-channel ACD/DAC 410 to a DSDmulti-channel recorder 420. The cable 405 is a category 5 unshieldedtwisted pair cable. This cable has four signal pairs, two pairs of whichare used to transmit and receive audio data, encoded using Ethernetphysical layer technology and the remaining two pairs of which are usedto convey a DSD sample clock in both directions across the link (seeTable 1 below). The clock signal and the audio data signal areconditioned to decrease the likelihood of interference between the twosignals degrading the quality of the clock signal. The clock signal isused to synchronise a phase locked loop (PLL) in the receiving device,which in turn may be used as a sample clock for ADCs and DACs. Anyjitter on the sample clock is undesirable since it will manifest itselfas distortion on the reproduced analogue audio output. The audio signalis intrinsically digital and consequently more robust to degradationthan the clock signal. A packet data transmission system such asEthernet is capable of carrying the DSD audio data. In this particularembodiment, the physical layer of Fast Ethernet (100BASE-TX) is used toprovide a channel bit-rate of 100 Mbit/s which accommodates audio datafrom 32 DSD channels on a single link. In an alternative embodiment the100 Mbit/s link is used to support 24 DSD channels on a single link.

Ethernet is an asynchronous data link and is thus inherently unsuitablefor transmission of the high-integrity, 64 F_(s) audio clock signal. Forthis reason the audio sample clock is transmitted on separate signalpairs of the category 5 UTP cable.

The single cable connection in FIG. 3 is fundamentally a point to pointlink directly connecting the two audio devices. It uses a special“crossover” category 5 cable that is wired to reverse the input/outputconnections. In this case a custom made crossover cable is requiredbecause conventional crossover cables such as those used for officenetworking do not reverse the two spare signal pair connections used inthis embodiment for transmission of the audio sample clock.

In alternative embodiments of the invention, such as that illustrated inFIG. 4, more complex interconnections can be formed between severalindividual items of DSD equipment. The apparatus illustrated in FIG. 4comprises a star-configuration DSD router 430, a multi-channel ADC/DAC440, a DSD mixer 450 and a DSD multi-channel recorder 460. Threepoint-to-point links 445, 455 and 465 are connected together via thecentral DSD router 430. Unlike the connection of FIG. 3, standardcategory 5 cable can be used for each of the three connections in thisstar configuration. This is because the port connections on the routerare internally reversed such that signal outputs of one device connectto signal inputs of another device.

The router 430 comprises a number of signal transceivers, eachtransceiver comprising a data clock transmitter (described below withreference to FIG. 6) and a data and clock receiver (described below withreference to FIG. 7). Switching and routing functions are carried out bya crosspoint switch (not shown) acting on the recovered clock andstreamed audio data. In other words, signals are not transferred acrossthe router in packetised form.

The cable 405 linking the transmitter device to the receiver device inFIG. 3 is terminated with 8-terminal RJ45 plugs and both transmitter andreceiver devices are fitted with RJ45 sockets. The table below specifiesthe setting of the RJ45 socket terminal connections for the audiodevices of FIG. 3 and for the star-configuration router devices of FIG.4. TABLE 1 Pin Function Function number (audio device)(star-configuration router) 1 Data transmit + Data receive + 2 Datatransmit − Data receive − 3 Data receive − Data transmit − 4 Clocktransmit + Clock receive + 5 Clock transmit − Clock receive − 6 Datareceive + Data transmit + 7 Clock receive − Clock transmit − 8 Clockreceive + Clock transmit +

FIG. 5 schematically illustrates an audio data transmission systemaccording to an embodiment of the present invention. The apparatus 500comprises a first audio processing device 510 and a second audioprocessing device 520 linked by a category 5 unshielded twisted paircable 515. Each audio processing device comprises a Field ProgrammableGate Array (FPGA) 512, a physical layer interface (PHY) 514, atransformer 516 and an RJ45 8-pin connector 518. The FPGA 512 provides aMultichannel Audio Connection for DSD (MAC-DSD).

1-bit 64 Fs direct stream digital data is supplied from the audio deviceto the FPGA 512. During a transmission operation the FPGA 512 performsaudio data buffering and framing operations whereas during datareception the FPGA extracts data from the framed structure and convertsit back to a DSD stream. The FPGA performs transmission and receptionconcurrently, implementing a full-duplex audio connection. The format ofthe data frames will be described in detail below with reference toFIGS. 15 and 16. The PHY device 514 performs physical layer coding ofthe framed audio data, implements spectrum control processing and hasline drivers that amplify the current and hence the power of the signalto increase its robustness during transmission. The PHY device 514effectively implements the Physical Coding Sublayer (PCS), PhysicalMedium Attachment (PMA) and Physical Medium Dependent (PMD) sub-layersof the physical layer 210. In this embodiment the PHY device 514 is anIntel™ LXT972a component and it operates in full duplex mode with noauto-negotiation and with data scrambling on. The transformer 516outputs the data for transmission on the category 5 cable 515. Onreception the transformer 516 receives the signal prior to physicallayer processing. The interface between the FPGA 512 and the PHY device514 is a Media Independent Interface (MII). Thus the FPGA replaces thenetwork address handling Media Access Controller (MAC) of theconventional Ethernet system. Multiple sample rates are supported andthe system is able to accommodate potential developments towards higherDSD sample rates. Any change to the audio sample rate affects the wayaudio data streams are packed into data frames and this functionality isdetermined by circuitry in the FGPA 512. Provided that the physicallayer link has sufficient bandwidth changes in the audio sample ratehave no effect on the PHY device 514.

FIG. 6 schematically illustrates how the 64 F_(s) audio sample clocksignal is transmitted in parallel with the DSD audio data alongdifferent signal pairs of the category 5 cable. As in FIG. 5, the FPGA512, the PHY device 514 and the transformer 516 perform the audio datasignal processing prior to its transmission on two signal pairs of theCategory 5 UTP cable 515. The 64 F_(s) audio sample clock is supplied asinput both to the FPGA, which performs framing and buffering, and to alow pass filter 552. The low-pass filter serves to reduceelectro-magnetic emissions during transmission of the clock signal. Theoutput of the low-pass filter 552 is supplied as input to a differentialline driver 554 and is subsequently fed through a 10BASE-T type Ethernettransformer 556. The clock signal is fed via the RJ45 connector 518 ontoa signal pair on the category 5 UTP cable 515 where it is transmitted inparallel with the audio data. Transmission of the audio sample clocksignal is important since it enables the FPGA of the receiving device toresynchronise the received audio data and thus to reconstitute the DSDbitstreams. The category 5 UTP cable used in this embodiment of theinvention has a characteristic impedance of 100 Ohms. Alternativeembodiments may use screened twisted pair cable which gives enhancedelectromagnetic compatibility (EMC) performance. Further alternativecable types that may be used include category 5e cable (for data ratesof up to 250 Mbit/s), category 6 cable (suitable for Gigabit Ethernet orcategory 7 cable which allows even higher data transmission rates.

The FPGA is only one solution to achieve the functionality required atthe transmitter and receiver. Software-controlled general purposemicroprocessors may of course be used, in which case the software couldbe provided by a storage medium (e.g. a read-only memory, flash memory,magnetic disk or optical disk) or a transmission medium (e.g. a networkor the internet).

FIG. 7 schematically illustrates reception of the high frequency audiosample clock in parallel with reception of the DSD audio data signal.The parallel signals are received from the cable 515 at the RJ45connector 522 of the receiving device. The DSD audio signal is receivedby a transformer 524 and is then supplied to a physical layer interface526 followed by an FPGA 528 which unframes the data and produces a DSDbit stream. The DSD audio stream is output from the FGPA according to a64 Fs clock signal 529 derived from the local phase locked loop of thereceiving device.

The received audio clock signal is supplied to a transformer 562 onarrival at the receiving device. The output of the transformer issupplied to a high pass filter 563 and then to a low pass filter 564,which is of the same type as the low pass filter 552 in the transmittingdevice. The low pass filter 564 in the receiver serves to remove anyhigh frequency interference in the received signal, derived either fromthe audio data signal, which it travelled adjacent to along the cable515, or from external sources. The output from the low-pass filter issupplied to a comparator 568 where it is converted to a logic signal.The logic signal from the comparator is used to drive a local phaselocked loop (PLL) circuit. A phase locked loop (PLL) is an electroniccircuit that controls an oscillator so that it maintains a constantphase angle relative to a reference signal. In this case the receivedhigh frequency clock signal is the reference signal. The PLL circuitgenerates a local audio reference clock which is used for reproductionof the DSD audio data.

FIG. 8 schematically illustrates the signal path of the 64 Fs DSD sampleclock signal. As explained above, the DSD sample clock is transmitted inboth directions via dedicated differential signal pairs in the category5 UTP interconnection cable 515. The sequence of processing operationsperformed on the high frequency (64 F_(s)) clock signal will now bedescribed with reference to FIG. 8. Special analogue conditioning of thesample clock signal is performed to facilitate its transmission on asignal pair of the UTP cable adjacent to the asynchronous data signal.The analogue conditioning reduces the severity of electromagneticinterference effects from the asynchronous data signal (or from externalsources) which compromise the integrity of the high frequency sampleclock signal. As schematically illustrated in FIG. 8, the sample clockprocessing that occurs in the clock master system involves the low passfilter 552, the differential line driver 554 and the transformer 556.The sample clock processing chain in the clock slave system involves thetransformer 562, a high pass filter 563 and the comparator 568.

The input to the low pass filter 552 of the clock master is a 2.8224 MHz(64 Fs) logic signal 551. The frequency tolerance of this signal is inaccordance with the Grade 2 specification defined by the standardsdocument AES11-1997. Accordingly the sample clock has a long-termfrequency stability of +/−10 parts per million (ppm), with an externalsynchronisation range of +/−50 ppm. The duty cycle of the sample clockin the range 40-60% and a Low Voltage Transistor-Transistor Logic(LVTTL) logic signal is used.

The 64 Fs logic clock signal 569 output by the comparator 568 of theclock slave system is also a logic signal of frequency 2.8224 MHz (64Fs). This clock output signal 569 is not used to synchronise any digitalaudio components directly because the link 515 characteristics may wellhave introduced substantial jitter and asymmetry to the clock signal.Rather, the clock output signal is used exclusively to synchronise anedge-triggered phase locked loop (PLL) in the receiver system. The clockoutput signal 569 is carefully routed within the receiver to ensure thatany noise and jitter on the signal does not couple into otherhigh-quality clock signals. The PLL circuit (not shown) of the clockslave system is used to generate high quality audio clock signals fordistribution throughout the receiving system.

The low pass filters 552, 564 in both the transmitting (clock master)system and receiving (clock slave) system are second-order low-passButterworth filters, each having a cut-off frequency fc=2.9 MHz.

The transmitter low-pass filter 552 attenuates high-frequency componentsof the clock signal that may otherwise cause interference with theadjacent audio data signals in the cable or cause excessive RF emissionsfrom the cable. The receiver low-pass filter 564 on the other hand,removes high-frequency interference from the clock signal induced byeither the adjacent high-frequency data signals or by external sources.

The differential line driver 554 located in the transmitter generates asymmetrical output signal of differential peak-peak voltage 1.5V-2.5Vinto 100 Ohms (the impedance of the category 5 UTP link).

The transformers 556, 562 in both transmitter and receiver are 10Base-TEthernet transformers having a 1:1 turns ratio and line-side common modechokes.

The high-pass filter 563 in the receiver is a first-order high passfilter having a cut-off frequency fc=500 Hz. This filter removeslow-frequency interference from mains supply sources, and blocks DCoffset. This filter is implemented with a simple resistance-capacitance(R-C) combination.

The comparator 568 in the receiver converts the filtered analogue clocksignal from the low pass filter 564 into a logic signal. In order toavoid or reduce noise-induced multiple edges a 2% hysteresis is used.

FIG. 9 shows an embodiment of the invention in which the synchronisationof the physical layer device is adjusted so it is an exact multiple(9*64 F_(s)) of the audio sample clock frequency 64 F_(s). The Ethernetstandard specifies a 25 MHz symbol rate for data transmission. It isconceivable that transmission of the 2.8224 MHz sample clock along thesame category 5 UTP as a asynchronous 25 Mhz audio data signal couldresult in undesirable degradation of the audio clock. Synchronising theaudio data transmission with the sample clock may help to reduce thedegradation of the high-quality audio clock signal. The apparatus shownin FIG. 9 comprises a multiplier 572 which takes a 64 F_(s) clock signalas input and up-converts it in frequency by a factor of 9 using a phaselocked loop. The output from the ×9 multiplier 572 is input to the PHYdevice of the transmitter so that a 576 F_(s) (25.4016 MHz) audio datasignal is generated. Accordingly, this embodiment uses a 25.4016 MHzsymbol rate for audio data transmission rather than the standard 25 MHzEthernet symbol rate. As a consequence of the increased symbol rate thechannel bit rate increases from 100 Mbit/s to 101.6064 Mbit/s.

Therefore, this embodiment of the invention can potentially reducedegradation of the audio clock signal but this is at the expense ofremoving compatibility with the 25 MHz symbol rate of standard Ethernetsystems.

FIG. 10 schematically illustrates a point-to-point audio link in whichone device acts as a clock master 600M whilst the other device acts as aclock slave 600S. Each of the audio processing devices comprises a clocksource PLL 602M/602S, a clock receiver (Rx) 604M/604S, a lock detectmodule 606M/606S, a clock transmitter (Tx) 608M/608S, an audioinput/output (I/O) system 610M/610S and a switch 612M/612S. The suffix Mdenotes a component associated with the master device 600M whereas thesuffix S indicates a component associated with the slave device 600S.DSD audio data passes along a UTP cable (not shown) which links theaudio I/O system 610M of the master with that of the slave 610S.

The category 5 UTP cable provides independent connections such thatunder normal operating conditions clock signals are transferred in bothdirections between two audio devices. However in an active link one ofthe devices must be designated clock master 600M and the other device isthus designated the clock slave 600S. The clock master transmitter 608Msends an audio clock signal 605M to the clock receiver 604S of the clockslave. The master clock signal 605M is used by the phase locked loop602S of the slave to produce a synchronisation signal that is suppliedto the slave audio I/O system 610S. The audio clock signal 605S that issent from the slave transmitter 608S to the clock receiver of the master604M is not supplied to the phase locked loop 602M of the master becausethe switch 612M of the master is left in an open state. However theslave clock signal 605S is compared with the local master clock by thelock detect module 606M of the master device to detect synchronisationof the remote slave system.

FIG. 11 is a flow chart which illustrates the sequence of eventsfollowed to establish a synchronised link between the master device andthe slave device of FIG. 10.

At stage 620 the transceiver of device B 600S is set to slave mode andthe clock transmitter 608S is temporarily disabled (until the link isestablished and a lock state has been achieved). This acts as asafeguard against two slave devices attempting to synchronise each otherwith unpredictable consequences.

At stage 630 the UTP cable is used to physically connect the masterdevice 600M to the slave device 600S thereby establishing the link. Onconnection of the cable both the master device 600M and the slave device600S detect that the link is currently valid. The master device beginstransmitting the clock signal 605M but the slave device's clocktransmitter 608 is temporarily disabled.

At stage 640 the slave device's clock receiver 604S detects the incomingmaster clock signal 605M and feeds this to the local slave phase lockedloop circuit 602S which locks to the incoming master clock signal.

At stage 650 the slave device 600S detects the lock condition bycomparing its local system clock with the incoming master clock signal605M via the lock detect module 606S. Closing the switch 612S completesthe circuit between the slave PLL 602S the slave clock receiver 604S andthe slave lock detect module 606S and thus enables lock detection. Oncethe slave lock detect module 606S signals that lock with the masterclock has been established, the slave clock transmitter 608S is switchedfrom the disabled state to an enabled state and the slave device 600Saudio buffers (located in the audio I/O system 610S) are reset.

At stage 660 the master device clock receiver 604M receives the echoedclock signal from the recently enabled slave clock transmitter 608S andchecks the phase of this echoed signal to verify that the slave devicehas synchronised correctly with the master clock signal 605M. Ifsynchronisation has not been correctly established then audiotransmission is not enabled.

At stage 670, having established that the slave device is correctlysynchronised the master device resets its audio buffers (located in theaudio I/O system 610M) and enables audio data transmission, whereuponframed DSD audio data is sent along the UTP cable linking master andslave devices.

The flow chart of FIG. 11 describes the standard process of establishingsynchronisation between the master device and the slave device. However,it may be the case that an attempt is made to establish a link betweentwo audio devices, both of which have been set to slave mode. In thisevent, the clock transmitters of both devices are disabled at the pointwhere the devices detect a valid data link and an indication is made tothe operator that the link is not synchronised. The link conditions areindicated to the user via LED status indicators (not shown) locatedadjacent to the RJ45 cable connection ports. Table 2 below gives an LEDstatus for each of a number of possible link conditions. In particular ared or yellow LED “on” status corresponds to a clock synchronisationfailure of the type that would be encountered during an attempt to linktwo slave mode audio devices. TABLE 2 LED status Condition No LED on NoEthernet PHY connection detected Red (or yellow) Ethernet PHY connectiondetected, but clock LED on synchronisation failed/not present/notlocked. Audio transfer inhibited Green LED on Ethernet PHY connectiondetected, slave device has locked to master device clock, and link isactive Both LEDs on (illegal indication)

FIG. 12 schematically illustrates an apparatus in which multipleparallel links are used between two pieces of audio equipment. Use ofmultiple links means a higher channel count is achieved than thatachievable via a single point-to-point link. In this case two links areused to provide a total of 64 channels. A transmitter device 700Acomprises a first transmitter 702, a second transmitter 704 and a clockgenerator 706. A receiver device 700B comprises a first receiver 712, asecond receiver 714 and a clock generator 716. A first category 5 UTPcable 721 carries audio data channels 1 to 32 (or 1 to 24) and links thefirst transmitter 702 to the first receiver 712. A second category 5 UTPcable 723 carries audio data channels 33 to 64 (or 25 to 48) and linksthe second transmitter 704 to the second receiver 714.

When operating the apparatus of FIG. 12, it is necessary to ensure thatthe DSD audio data streams output by the first receiver 712 aresample-synchronised with the DSD audio data streams output by the secondreceiver 714 i.e. the samples from channels 1 to 32 (or 1 to 24) aresynchronised with the samples from channels 33 to 64 (or 25 to 48). Thetransmit and receive latencies of the PHY devices in the transmitters702, 704 and in the receivers 712, 714 mean that it is possible that theoutput of receivers 712, 714 could slip out of synchronisation by morethan one DSD audio sample period (3.543×10⁻⁷ seconds). Manufacturerspecifications for commonly used PHY devices indicate that combinedtransmit and receive latencies of the PHY devices could vary by up to6×10⁻⁸ seconds so that slippage of one DSD sample between receivers isconceivable. Any differences in the lengths of cables 721 and 723 willalso affect synchronisation.

As shown in FIG. 12, the first and second transmitters 702, 704 of thetransmitting audio system 700A use a common synchronisation referenceclock signal F_(s)(A) running at F_(s)=44.1 kHz. Similarly the first andsecond receivers 712, 714 of the receiving audio system 700B use acommon synchronisation reference clock F_(s)(B) running at F_(s)=44.1kHz. These two 44.1 kHz synchronisation clock signals F_(s)(A) andF_(s)(B) have identical frequencies both having been derived from a 64Fs master clock signal, but their phases, being arbitrary, are unlikelyto match. The arbitrary phases are due to F_(s)(A) and F_(s)(B) havingbeen derived from the common 64 Fs clock via independent clock dividers.The flow chart of FIG. 13 illustrates how the signals F_(s)(A) andF_(s)(B) are employed to ensure that the outputs of receivers 712 and714 (which have derived their audio data from separate link cables 721and 723 respectively) are kept synchronous.

At stage 730 of the flow chart of FIG. 13, a communication link betweenthe transmitting system 700A and the receiving system 700B isestablished. Each of the two transmitters 702, 704 awaits receipt of aclock edge from the local 44.1 kHz clock signal F_(s)(A) and thentransmits the first audio frame. The data frame is packed such that thefirst DSD sample is input synchronously with the clock edge. The flowchart of FIG. 13 relates to an embodiment in which there are 32 channelsof DSD audio. As shall be described in detail below with reference toFIG. 18A, for the 32-channel system each frame comprises 384 data wordsand words 13 to 382 each contain a 1-bit DSD sample value for each of 32channels (370 sample values per channel are contained in each frame).The first transmitter transmits the first audio frame corresponding tochannels 1 to 32 whilst the second transmitter transmits the first audioframe corresponding to channels 33 to 64. Since in this embodiment eachframe contains 370 samples and there are 64 samples per Fs period, acoincident frame start (1^(st) DSD sample value output) and Fs-periodstart (Fs(A) clock edge) will occur every 370×64 samples. However, 370and 64 have a common factor of 2 so a frame-start and Fs period-startoccur together every (370*64)/2 samples i.e. every 32 frames.Accordingly, the 1^(st) DSD sample value of the frame will be outputsynchronously with the local F_(s)(A) clock edge for frames 1, 33, 65,97 . . . and so on. These particular frames have a specific bit flag ina “frame type” field (see FIG. 16) of the data frame set to one.

At stage 732 of the flow chart both the first receiver 712 and thesecond receiver 714 capture a phase count value Φ_(j) (j=1 or 2corresponding to first and second receivers respectively) marking thepoint in time at which the first DSD sample value in the first receivedframe is ready for output. Note that at system start-up the receiveraudio outputs are muted and transmitter audio outputs are only enabledonce synchronisation of the 64 Fs sample clocks has been verified by themaster device. The time at which the receiver is ready to output thefirst DSD sample value will depend on the time taken for the slavedevice to achieve phase lock with the 64 Fs clock signal of the masterdevice. It will also depend on the setting of the threshold level of aFIFO buffer of the particular transmitter. Each receiver derives thephase count value Φ_(j) from a counter in the receiver which is clockedby the 64 F_(s) local clock signal and reset by the 44.1 kHz signalF_(s)(B).

At stage 734, a system controller (not shown) compares the phase countvalues, Φ₁ and Φ₂, for each of the receivers and determines if they areidentical. If Φ₁=Φ₂ then the receivers are synchronised to within thesame DSD sample period which is the desired condition. In this event theprocess proceeds to stage 738 where the audio outputs are unmuted. Ifhowever, Φ₁≠Φ₂ at stage 734 then the process proceeds to stage 736 wherethe system controller adjusts the buffer read positions of the receiversin an attempt to achieve synchronisation. The receiver that synchronisedwith the 64 Fs master clock earliest (and hence received DSD audio datafirst) has its buffer read position adjusted to match the buffer readposition of the latest synchronised receiver (which started to receiveDSD data later). This buffer read position adjustment is equivalent tomodification of the phase count values Φ_(j) such that they are bothequal to the higher of the two compared phase counts. Only whensynchronisation has been achieved i.e. when the phase count values ofthe receivers are identical will the audio outputs be enabled.

The phase count values of the receivers are cross-checked for everyflagged frame (first frame and every following 32^(nd) frame) to ensurethat synchronisation of the receivers is maintained. Frames aretransmitted every 131.25 μs so that flagged frames occur approximatelyevery 4.2 ms (32×131.25 μs). Any receiver synchronisation problem shouldbe detectable and correctable within this 4.2 ms period. Stages 742,744, 746, of FIG. 13 show the check that is performed by the systemcontroller for every flagged frame. At stage 742 the controller checksthe modified phase count value for the current flagged frame andcompares it with the final (possibly modified) recorded phase countvalue for the previous flagged data frame i.e. frame X-32. If the phasecount values match then the system continues with audio datatransmission at stage 746. If however the phase count values for the twoflagged frames do not match, this indicates that the two receivers arenot outputting the same audio sample value simultaneously and theprocess proceeds to stage 744 where the system controller initiatesresetting of the data links in an attempt to restore propersynchronisation. When the data links are reset the receiver logic is putin a reset condition so that the process of stages 732 to 738 of FIG. 11is carried out. In alternative embodiments the data links are reset byadjustment of the buffer read positions, but in this case a bufferoverrun/underrun would trigger a total reset of the link. Samplesynchronisation slippage could occur, for example, due to a cableglitch.

For the alternative 24 DSD channel embodiment, as shall be described indetail below with reference to FIG. 18B, each frame comprises 368 datawords and words 15 to 366 contain 352 DSD samples for 24 channels plus88 bytes of auxiliary data. Each 32-bit sample comprises 1-bit from eachof the 24 DSD channels, 2 bits of auxiliary data and 6 check-bits. Bit 0of each sample corresponds to the first logical audio channel whereasbit 23 corresponds to the 24^(th) logical audio channel. In this casethe first transmitter transmits the first audio frame corresponding tochannels 1 to 24 whilst the second transmitter transmits the first audioframe corresponding to channels 25 to 48. Since in this embodiment eachframe contains 352 samples and there are 64 samples per Fs period, acoincident frame start (1^(st) DSD sample value output) and Fs-periodstart (Fs(A) clock edge) will occur every 352×64 samples. However, 352and 64 have a common factor of 32 so a frame-start and F_(s)period-start occur together every (352*64)/32 samples i.e. everyalternate frame. Accordingly, in the 24 DSD channel embodiment the1^(st) DSD sample value of the frame will be output synchronously withthe local F_(s)(A) clock edge for frames 1, 3, 5, 7, 9 . . . and so on.It follows that every alternate frame will be a flagged frame and thephase count values of the receivers will be cross-checked everyalternate frame.

FIG. 14 schematically illustrates how audio data buffering is performedin the transmitter. The buffering apparatus 800 comprises a First InFirst Out (FIFO) buffer 810 in series connection with a frame assembler820. In operation, 32 channels of Direct Stream Digital 1-bit sampledata are continuously fed into the FIFO buffer at a rate of 64 Fs whichcorresponds to 90.3168 Mbit/s. When the occupation level of the FIFObuffer reaches a predetermined threshold level 815 a signal is generatedby the system controller to initiate transmission of a new audio dataframe. In response to this signal, the frame assembler assembles theframe preamble and headers, during which time incoming DSD samplescontinue to be buffered. As soon as the audio data payload assemblybegins, the frame assembler starts to extract data from the FIFO. Therate at which data is extracted from the FIFO corresponds to theEthernet transmission rate of 100 Mbit/s (or 101.6064 Mbit/s forembodiments in which the symbol rate is locked to 9*64 F_(s)). Since theFIFO is filling at a rate of 90.3168 Mbit/s and emptying at a rate of100 Mbit/s the net buffer occupation level will steadily decrease duringthis period. The predetermined threshold level 815 is set in dependenceupon the data input rate, the data output rate and the frame size (3701-bit samples for 32 channels) so that the buffer occupation level willbe almost, but not quite, zero at the end of each frame transmissioni.e. data from the next frame for transmission is present in the buffer.The fact that the transmitter buffer 810 is not completely empty by thetime the frame transmission ends breaks the rules of the MAC. Once theframe transmission is complete the FIFO occupation level will increaserapidly until the threshold level is reached whereupon the frametransmission cycle will repeat.

For a transmission system with an input data rate of 90.3168 Mbit/s, anoutput rate of 101.6064 Mbit/s and a (370 1-bit sample) (32 channel)frame capacity it can be shown that the minimum buffer size is 42 DSDsamples and the corresponding minimum threshold level is 30 DSD samples.The audio latency introduce by this minimum size buffer is 14.9 μs(=42/64 Fs).

FIG. 15 schematically illustrates how audio data buffering is performedat the receiver. The receiver buffering apparatus comprises a framereceiver 860 in series connection with a FIFO buffer 870. Audio dataarrives (via the category 5 UTP cable) in framed format at the framereceiver 860 at a rate of 100 Mbit/s (or 101.6064 Mbit/s for the 9*64F_(s) symbol rate). The frame receiver strips off the preamble andheaders of each data frame and optionally performs a cyclic redundancycheck (CRC) to verify the integrity of the received data. Unframed audiodata is passed directly from the frame receiver 860 to the FIFO buffer870. Audio data extraction from the FIFO starts immediately since thereis no threshold level set in the buffer at the receiver. This ensuresthat near-zero receiver latency is achieved. The audio data framescontain a cyclic redundancy check word (CRC). The CRC algorithm, checkword location and scope are as defined in IEEEE802.3-2000 section 3.2.8.This 32-bit check word will generally detect any error within the frame.In known Ethernet systems a CRC is performed on each frame both at thetransmitter and at the receiver. At the receiver complete frames areoutput only once the result of the CRC on that frame is determined. Thisresults in substantial latency before the data is output at the receiverin known systems. According to the present technique, although the CRCcheck is still performed at the receiver, data is output from the bufferbefore the result of the CRC check is obtained. Error control isperformed by decoding parity bits at a stage subsequent to data outputat the receiver FIFO. In particular, error control is performed whendata is extracted from the 32-bit data blocks prior to output as a 32DSD channel audio stream. Unlike standard Ethernet systems, the MAC-DSDprotocol according to the present technique does not support framere-transmissions in case of an error, as this would require buffering ofat least two 125 microsecond audio frames, increasing system latency toan unacceptable degree. Although the primary purpose of the IEEE802.3CRC is to detect frame errors and thereby generate a retransmissionrequest, the CRC is included for sake of compatibility. It will beappreciated that support for CRC-initiated MAC-DSD frame retransmissionmay be provided for applications requiring greater robustness at theexpense of latency. Audio data is extracted from the FIFO at acontinuous rate of 90.3168 Mbit/s and because the data output rate isless than the data input rate, the FIFO gradually fills up as the frameis received. Once a complete frame has been received there will be aninter-frame latency time before reception of audio data from the nextframe and the FIFO buffer will continue to empty (although notcompletely) during this idle period.

In the event that the receiver buffer fills completely or emptiescompletely an error signal will be sent to the system controller. Inthis event the system controller will mute the audio outputs because acompletely full or empty buffer indicates that one of the followingsituations has arisen: data link has failed; transmitter has failed; orDSD master clocks have not been properly synchronised betweentransmitter and receiver.

FIG. 16 schematically illustrates the data structure of a standardEthernet frame. The frame structure is defined in the IEEE 802.3standard. As shown in FIG. 16 the Ethernet frame comprises a preamble, astart frame delimiter, a destination address field, a source addressfield, a data length field, a data payload and a checksum.

The preamble is 7 bytes long, each byte containing the bit pattern10101010 and this is followed by a single-byte start frame delimiter Scontaining the bit pattern 10101011. The preamble and start framedelimiter are used for hardware timing purposes. The destination addressfield is 6 bytes long and specifies the physical address of the networkadapter that is to receive the frame. The source address field is 6bytes long and contains the physical address of the network adapter thatis sending the frame. The data length field is 2 bytes long andspecifies the size of the data payload. The data payload is a variablelength field which is a minimum of 46 bytes and a maximum of 1500 byteslong. The checksum field is 4 bytes long and contains a checksum valuefor the frame that is used to perform a cyclic redundancy check (CRC).The CRC is a common means of verifying data transmissions. The sendingnetwork node calculates a CRC value for the frame according to apredetermined algorithm and encodes it in the frame. The receivingnetwork node then recalculates the CRC and checks the CRC field to seeif the values calculated by the transmitter and the receiver match. Ifthe values do not match this indicates that data has been lost orcorrupted during transmission. This Ethernet frame will be passed to thePhysical layer components where it will be converted to a bit stream andsent across the transmission medium. Note that slight variations of thisEthernet frame format exist.

FIG. 17 shows the structure of an audio data frame according to anembodiment of the present invention. The audio data frame has a totalsize of 1536 bytes comprising: an 8 byte preamble (following which thephysical layer will accept up to 1528 bytes of arbitrary data); a 6-bytefield reserved for the destination MAC address (default value 0xffffff);a 6 byte field reserved for the source MAC address (default value0x000000); a 2-byte data length field which specifies the number ofbytes (always 1510 bytes) following this field but excluding the CRC; a28-byte field reserved for networking headers; a 12-bit reserved field(as yet unallocated); a 4-bit frame type field which is used for examplefor synchronisation purposes; an audio data payload of 1480 bytes whichholds 370 samples of 32 channel DSD audio; and a 4-byte CRC fieldcontaining a checksum. The CRC checksum procedure used in embodiments ofthe invention will be described below. The audio data frame structureillustrated in FIG. 17 is of a form that allows for compatibility withInternet Protocol (IP) networks. Accordingly the audio data frame may betreated as a User Datagram Protocol (UDP)/IP datagram for transmissionover wider IP networks. UDP is a connectionless (best try) transportlayer protocol. In this particular embodiment only the physical layer isused. The MAC layer is not used so the MAC address fields are notactually required by the system. These fields are simply reserved andfilled with default values to allow (potential later) compatibility withLocal Area Networks (LAN) or UDP/IP.

The audio frame CRC validity check will now be described in more detail.All frames use a 4-byte CRC check word, to verify the validity of theframe. The CRC algorithm, check word location and scope are similar tothose defined in the standards document IEEE802.3-2000 section 3.2.8.

According to the IEEE802.3 standard, the payload of a frame should notbe passed on from the data link layer until the frame validity has beenverified with the CRC. However, in the context of embodiments of theinvention, this implies that the receiver would have to buffer an entireframe before starting to output the DSD audio bitstreams. Directimplementation of this standard would be undesirable, as it wouldincrease the audio latency by 115 μs, from around 25 μs to 140 μs.

The CRC is primarily used to check the validity of a data link betweenaudio devices at system start-up. Link failures after start-up, such asa cable disconnection are indicated by a receiver error assertion fromthe PHY device, following which the audio output is muted. Since thelink is a simple point-to-point connection, with deterministic,synchronised frame transmission and no collisions, other modes offailure are unlikely.

Accordingly, a relatively simple CRC check is implemented in embodimentsof the invention. The receiver audio outputs are muted on start-up,until the first received frame has been received in full and verified byits CRC. If the CRC check fails, the audio outputs remain muted, and anerror condition indicated to the local system controller. Following theverification of the first frame, the CRC is only be checkedretrospectively. This allows audio data to be streamed out withnear-zero receiver latency. The CRC is used only to alert a hostprocessor that a CRC error has occurred.

If an invalid audio data frame is encountered, it is theoreticallypossible for up to 131 μs of invalid audio data to pass, before theoutput is muted in response to the retrospective CRC test. However, inpractice, a random external perturbation that corrupts PHY line symbolswill cause invalid symbols, resulting in rapid assertion of a receivererror condition, which may be detected to mute the audio outputs.

If use of a CRC check on every frame is considered necessary then eachframe is buffered and verified using the CRC before outputting the DSDaudio data. This is not a preferred option because it adds approximately115 μs extra latency and substantially increases the receiver bufferhardware size.

The 1536-byte audio data frames illustrated in FIG. 17 each have atransmit duration of 120.9 μs (at a symbol rate of 101.6064 Mbit/s).According to a particular embodiment of the invention, frames aretransmitted at intervals of 131.1 μs. A minimum inter-frame time of 96bit periods is provided which leaves 8.25 μs of “link-time” betweentransmission of audio frames. This link-time is used to convey auxiliaryframes containing control data. The maximum total size of a control dataframe in this embodiment is 104 bytes.

The structure of a control data frame is identical to that of the audiodata frame shown in FIG. 15, with the exception of the length of thedata payload which is 1480 bytes for the audio data frame but only 48bytes for the control data frame. A control data frame is transmittedevery 131 μs which provides a control data bandwidth of 2.9 Mbit/s. Thecontrol data itself may comprise channel usage information, routercontrol data and clock source control data. The control data will betransmitted from storage in a FIFO buffer at the transmitter andgathered in a FIFO buffer at the receiver before being routed to asystem controller of the receiver.

FIG. 18A shows the audio data frame format for the 32 DSD channelembodiment which is arranged as 384*4-byte data words. Similarly, FIG.19 shows the control data format for the 32 channel DSD embodimentarranged as 26*4-byte data words. In both FIG. 18A and FIG. 19, bit zero(B0) is transmitted first and bit 31 (B31) is transmitted last. Theseaudio data frames and control data frames are passed to and receivedfrom the Media Independent Interface (MII) connection 218 that providesa link to the Ethernet physical layer devices. The MII comprises a 4-bitwide transmit data bus and a 4-bit wide receive data bus each of whichis clocked from the PHY at the link rate of 25 MHz (or 25.4016 MHz). TheMII also has a transmit-enable signal input to initiate datatransmission and a receive data valid signal output as well as othererror and signal status indicators.

Referring now to the audio data frame structure illustrated in FIG. 18Ait can be seen that the payload of the audio data frame contains 370samples of 32-channel 64 Fs DSD audio. These channels are multiplexedper-bit. Each 32-bit word represents one 64 Fs DSD sample for 32 audiochannels. Word 13 is the first DSD sample in the frame, and word 382 isthe last. Bit 0 of an audio data word is always the single-bit sampledata for channel 1 (the first channel in the system) whereas Bit 31 ofan audio data word is always the single-bit sample data for channel 32(the last channel in the system). Table 3 below indicates how successivesamples for each channel are stored in the data words of the audioframe. For example: bit 0 of word 13 is the channel 1 sample data, forthe first DSD sample in the frame; bit 6 of word 14 is the channel 7sample data, for the second DSD sample in the frame; and bit 31 of word382 is the channel 32 sample data, for the last DSD sample in the frame.TABLE 3 Word Bit 31 Bit 30 . . . Bit 1 Bit 0  13 Ch. 32, sample 1 Ch.31, sample 1 . . . Ch. 2, sample 1 Ch. 1, sample 1  14 Ch. 32, sample 2Ch. 31, sample 2 . . . Ch. 2, sample 2 Ch. 1, sample 2 . . . . . . . . .. . . . . . . . . . . . . . . 382 Ch. 32, sample 370 Ch. 31, sample 370. . . Ch. 2, sample 370 Ch. 1, sample 370

Although Table 3 above represents the frame format in 32-bits words,these are supplied to and from MII four bits (a nibble) at a time ratherthan a word (4-bytes) at a time. The sequence of nibbles supplied to theMII for the single 24 DSD channel frame of FIG. 18B is as shown in Table4 below. The start of the 14^(th) data 4-byte word (word 13) correspondsto the start of the 105^(th) 4-bit nibble (nibble 104). The columnheadings TXD and RXD in the table below refer to the MII transmit andreceive data buses respectively, which transfer nibbles of datasynchronously with a 25 MHz (or 25.4016 MHz) clock.

Nibble 0 is the first nibble in the frame, and contains part of thepreamble pattern (0×5). Nibble 104 is the first nibble of the audio datafield (first nibble of word 13), and nibble 3063 is the last nibble ofthe audio data field (last nibble of word 382). TABLE 4A nibbleTXD(3)/RXD(3) TXD(2)/RXD(2) TXD(1)/RXD(1) TXD(0)/RXD(0)   0 0 1 0 1   10 1 0 1 . . . . . . . . . . . . . . .  104 channel 4 sample 1 channel 3sample 1 Channel 2 sample 1 channel 1 sample 1  105 channel 8 sample 1channel 7 sample 1 Channel 6 sample 1 channel 5 sample 1  106 channel 12sample 1 channel 11 sample 1 Channel 10 sample 1 channel 9 sample 1 . .. . . . . . . . . . . . .  111 channel 32 sample 1 channel 31 sample 1Channel 30 sample 1 channel 29 sample 1  112 channel 4 sample 2 channel3 sample 2 Channel 2 sample 2 channel 1 sample 2 . . . . . . . . . . . .. . . 3062 channel 28 sample 370 channel 27 sample 370 Channel 26 sample370 channel 25 sample 370 3063 channel 32 sample 370 channel 31 sample370 Channel 30 sample 370 channel 29 sample 370

FIG. 18B schematically illustrates the audio data frame format for the24 DSD channel embodiment. In this case the frame comprises 368*4-bytedata words. The payload of the audio data frame comprises 352 DSDsamples, each sample comprising 1-bit from each of the 24 channels. Datawords 15 to 366 contain the audio data payload. Words 2 to 4 arereserved for source and destination MAC addresses. Bits 0 to 15 of word5 specifies the total number of bytes in the frame from the beginning ofthe length field onwards but excluding the CRC field, which in this caseis 1446 bytes. Bits 16 to 31 of word 5, words 6 to 12 and bits 0 to 15of word 13 are data fields reserved for UDP and IP parameters. Thesedata fields facilitate optional use of UDP/IP. When UDP/IP operation isnot required the transmitter fills these fields with zeros. The receivermay ignore all these UDP/IP header fields, with the exception of thefirst four bits (bits 16 to 19 of word 5 in this case) which indicatethe IP Version. The data entry in the IP version field is checked and anaction is taken in correspondence with the determined value as specifiedin Table 5 below: TABLE 5 IP Header Value Consequent Action 0x0 Processframe as normal (i.e. transmitter did not fill IP fields) 0x4 Processframe as normal (i.e. transmitter filled frame header fields accordingto IP version 4) any other Discard the frame

The IP Version check is performed to ensure backwards compatibility ofthe current IP version 4 from future IP versions (i.e. IP version 6).Future IP versions may have different header lengths, and consequentlythe Frame Format ID fields may be located at a different position in theframe. The safeguard of checking the IP version field means that such aframe would be discarded by the receiver (due to having a value otherthan 0×0 or 0×4) which avoids the possibility of the frame beingincorrectly interpreted due to the Frame Format ID fields not being inthe expected location at words 13 and 14.

Bits 16 to 31 of word 13 and bits 0 to 31 word 14 in FIG. 18B are fieldsfor specifying the MAC-DSD frame format. This 48-bit frame format fieldis logically divided into three distinct 16-bit (4-nibble) sections,each of which contains an identical set of frame format data ontransmission. The same set of frame format data is repeated three timeswithin a given frame to ensure that the frame format identifier isrobust to transmission errors i.e. multiple copies of the data are sentto serve as an error protection mechanism. This data-repeat errorprotection mechanism has the advantage that it gives the required errorcorrection capability given that 48 bits are available to convey 16 bitsof information yet it is simple to implement. An alternative embodimentmight use an error correction code such as a convolutional code totransmit the frame format ID payload.

Each of the three 16-bit frame format field sections are structured asillustrated in FIG. 20. The first nibble (bits 0-3) of each 16-bitsection specifies the Protocol Minor Version (OxO-Oxf). The protocolminor Version field is used to indicate minor updates to the protocolspecification. A more recent Minor Version should be fullybackwards-compatible with a previous Minor Version associated with thesame Major Version so that for example a Version 1.7 protocol mustincorporate all the functionality of Version 1.6 protocol, and a Version1.7 transceiver must be able to communicate fully with a Version 1.6transceiver. The second nibble (bits 4-7) of each 16-bit sectionspecifies the Protocol Major Version (OxO-Oxf). This field is used toindicate major updates to the protocol specification.Backwards-compatibility with previous Major Versions of the protocol isdesirable but not mandatory. The third nibble (bits 8-11) of each 16-bitsection specifies the Frame Type (OxO-Oxi). This field can be used toindicate different frame types used by a given version of the protocol.Within a given Major Version level, the definitions of frame typesshould be consistent. The basic type of audio frame is always Type 0.The table below specifies the information derivable from the Frame typenumber specified by bits 8 to 11 according to the described embodiment.TABLE 6 Frame Type Number Name Description 0x0 DSD 352 DSD (2.8224 MHz)samples, 24-channel, audio plus 88 bytes aux data, (32, 26) Hammingframe linear block code error correction, 256-nibble interleaving other(invalid) Invalid - reject frame

The fourth nibble (bits 12-15) of each 16-bit section contains one ormore flags used for example to flag frames for synchronisation purposesas described above with reference to the flow chart of FIG. 13. Thedefinition of the flag bits is dependent upon the Major Version protocollevel. The table below specifies the information derivable from theframe flag bits 12-15 according to the described embodiment. Inparticular bit 0 of the flags field is the 44.1 kHzsync flag. If flag 0has a value 1 this indicates that the first DSD sample in frame wasreceived at transmitter simultaneously with 44.1 kHz sync clock positiveedge whereas if bit 0 of the flags field has value 0, this indicatesthat the first DSD sample in frame was not received at transmittersimultaneously with 44.1 kHz sync clock positive edge. TABLE 7 Flag bitName Description 0 44.1 kHz 1: First DSD sample in frame was received atsync flag transmitter simultaneously with 44.1 kHz sync clock positiveedge 0: First DSD sample in frame was not received at transmittersimultaneously with 44.1 kHz sync clock positive edge others (not used)Set to 0 by transmitter, ignored by receiver

FIG. 21 schematically illustrates the three 4-nibble sections of theframe format ID containing a set of data entries to be processed at thereceiver. Section 0 comprises nibble 0 (n0) to nibble 3 (n4), section 1comprises nibble 4 (n4) to nibble 7 (n7) and section 2 comprises nibble8 (n8) to nibble 11 (n11). The manner in which the repetition of datasections is used at the receiver to reject data transmission errors willnow be explained in the context of FIG. 21. According to the presenttechnique it is known that on transmission, each of the three sectionsshould contain an identical data set such that data entries incorresponding nibble positions of each of the three sections match. Onparticular it is expected that: n0=n4=n8; n1=n5=n9; n2=n6=n10; andn3=n7=n11. At the receiver triplets of corresponding nibbles arecompared for equality, and a majority decision is taken as to thecorrect data value. Consider the example incoming receiver data setshown in FIG. 21. For the first triplet of nibbles it can be seen thatn0=1101b, n4=1101b, n8=1101b i.e. the corresponding nibble values areidentical so the value is assumed to be correct and the first nibble ofthe Frame Format, which specifies the protocol minor version, is set tothe value 1101b. Similarly, for the second triplet of nibblesn1=n5=n9=1110b so the value is assumed to be correct and the secondnibble of the Frame Format, which specifies the protocol major version,is set to 1110b. However, for the third triplet of nibbles there is adiscrepancy between the data values since n2=n10=0110b but n6=1011b. Inthis case n6 is rejected as being erroneous on the basis of a majoritydecision so that the receiver and outputs the third nibble of the FrameFormat, which corresponds to the frame type, as 0110b. For the fourthand final triplet of nibbles it can be seen from FIG. 21 that none ofthe corresponding nibbles match n3=0010b, n7=0111b, n11=1100b. In thiscase a majority decision is impossible so the frame format cannot bedetermined and consequently the frame is rejected.

An alternative embodiment uses a modified Frame Format errordetection/correction strategy. This alternative strategy also involvesusing the data repetition and majority decision approach but thestrategy is augmented by using the 100Base-TX PHY ‘MII receive error’(rx_er) signal to flag nibbles that are known to be in error. Forexample consider receiving the following values for the fourth tripletof nibbles with associated error flags as indicated: n3=1000b(rx_er=true), n7=0100b (rx_er=false), n11=1000b (rx_er=true). In thiscase, although the majority decision determines that 1000b is thecorrect value, the rx_er signal indicates that n3 and n11 are definitelyincorrect. Thus according to this alternative strategy the data vale n7is selected in preference to n7 and n11 to give a Frame Format Flagsvalue of 0100b.

Returning now to the frame data fields of FIG. 18B, the last word (word367) of the 24 DSD channel data frame is a field containing cyclicredundancy check (CRC) data.

Table 4B below identifies the sequence of nibbles supplied to the MIIfor the single 24 DSD channel frame of FIG. 18B. This sequence istransmitted via the nibble-wide MII interface 218, starting with theleast significant nibble. Nibbles 0 to 8 (32 bits) correspond to word 0of FIG. 18B, nibbles 8 to 15 correspond to word 1 of FIG. 18B, nibbles16 to 23 correspond to word 2 of FIG. 18B and so on until the lastnibble which corresponds to bits 28 to 31 of word 366. There are a totalof 2936 nibbles (367 words) corresponding to the 1446 byte frame of FIG.18B since the last word is not transmitted as a nibbles. As mentionedabove with reference to FIG. 1 the MII 218 interface providesindependent 4-bit wide data-transmit and data-receive paths and fullduplex operation. More particularly, the MII 218 comprises: a four-bitwide transmit data bus, clocked from the physical layer interface (PHY)514, 526 at the link rate (25 MHz or 25.4016 MHz); a transmit enablesignal input; four-bit (nibble) wide receive data bus, clocked from thePHY at the link rate (25 MHz or 25.4016 MHz); a receive data validsignal output; and error and signal status indicators. A fulldescription of the MII interface, can be found in IEEE802.3-2000 Section22, but note that the clock rate according to the present technique maybe 25.4016 MHz rather than the IEEE standardised 25.0000 MHz. TABLE 4BWord (from MII MII MII MII Nibble FIG. 18B) TXD(3) TXD(2) TXD(1) TXD(0)  0  0 Bit 3 Bit 2 Bit 1 Bit 0   1  0 Bit 7 Bit 6 Bit 5 Bit 4 . . . . .. . . . . . . . . . . . .   7  0 Bit 31 Bit 30 Bit 29 Bit 28   8  1 Bit3 Bit 2 Bit 1 Bit 0 . . . . . . . . . . . . . . . . . . 2934 366 Bit 27Bit 26 Bit 25 Bit 24 2935 366 Bit 31 Bit 30 Bit 29 Bit 28

The nibble is the fundamental unit of data carried on the physicallayer. Each 4-bit nibble is mapped to a 5-bit symbol by the PHY 514,526, for transmission on the signal line 515. All frames fortransmission must begin with an eight-byte preamble pattern, followingwhich the physical layer will accept up to 1528 bytes of arbitrary data,supplied 4 bits at a time. Received frames are supplied 4 bits at a timeby the receive bus, including the preamble.

The 24 DSD channel frame format of FIG. 18B includes a frame payload of352 DSD samples, each of which consists of a 32-bit data block. FIG. 22schematically illustrates the format of the 32-bit data block. Each datablock corresponds to a single DSD sample period of approximately 354 ns.The data block comprises a 24-bit audio data vector each bit of whichbelongs to a respective one of the 24 audio channels, 2 bits ofauxiliary data and 6 check (or parity) bits. As shown in FIG. 22 bitnumbers 0 to 14 contain bits 1 to 15 of the audio data vector, bitnumbers 15, 23, 27, 29, 30 and 31 contain the six parity bits, bitnumbers 26 and 28 contain the two bits of auxiliary data and theremaining nine bits of the audio vector are contained sequentially inbit numbers 16 to 22, 24 and 25 of the data block.

The six parity bits of the 32-bit data block provide error controlcapability. The 24-bits of audio data plus the two auxiliary bits(totalling 26 bits) are encoded using a type of linear block code knownas a Hamming code. In this case a (31, 26) Hamming code is used, whichmeans that 5 (=31−26) parity bits are generated by the code for eachgroup of 26 data bits. The final bit of the 32-bit block is a globalparity bit so there are a total of 6 parity bits and 26 data bits. The(31, 26) Hamming code is capable to detecting 2 errors per data blockbut is only capable of correcting one error per data block.

FIG. 23A schematically illustrates how the six parity bits P0 to P5 aregenerated from the 24 audio data bits (numbered 1-24) and the twoauxiliary data bits A0, A1. Parity bits P0 to P5 are generated byperforming a logical XNOR operation on a predetermined sequence of 15data elements. For example P0 is generated by performing an XNORoperation on audio vector bits 1 through 15 whereas P1 is generated byperforming an XNOR operation on audio vector bits 1 to 8 and 16 to 22.Global parity bit P5 is obtained by performing the XNOR operation on all26 data elements. The error detection process at the receiver involvesdetermining whether the parity checks are satisfied in the received datasequence. This is done using a value known as the syndrome. FIG. 23Bindicates how the syndrome s is generated by XNOR operations on variouscombinations of the received data block elements. The syndrome isobtained by comparing the received parity bits and the parity bitsrecalculated from the received information. Table 8 below indicates howthe value of the syndrome is used to detect and correct errors in thereceived data block. Essentially, if all 6 bits of the syndrome havevalue 1 (s=111111) then the received data sequence is assumed to becorrect. If the sixth bit of the syndrome is zero then there is assumedto be a single error in the received data block, which is correctable byinverting the appropriate bit. The appropriate bit is identified fromthe value of the syndrome itself e.g. if s=011011 in binary notation,which corresponds to the decimal number 27 then it is determined thatbit number 27 (of bits 0 to 31) should be inverted to correct the datablock. If the sixth bit of the syndrome is 1 but the other five bits arenot all 1 e.g. s=111011 then this indicates that there are two or moreerrors in the block and the multiple errors are uncorrectable. TABLE 8s₅ s₄s₃s₂s₁s₀ Block status 1 11111 No errors in block 0 other One errorin block, identified by s₄s₃s₂s₁s₀ - correct error by inverting bit 1other More than one error in block - not correctable

The 32-bit data blocks (see FIG. 22) are interleaved in groups of 32, tofacilitate correction of groups of errors. The interleaving processinvolves permuting the data in a predetermined way. This is requiredbecause the (31, 26) Hamming code used for each 32-bit data block isonly capable of correcting a single bit error in a given block. Sincethe fundamental unit of data on the physical layer the four-bit datanibble, a single instantaneous corruption on the physical layer willcause a symbol error (recall that a symbol is a 5-bit quantity),resulting in four consecutive bit errors. To facilitate correction ofsuch 4-bit burst errors the erroneous bits must be distributed amongstfour different 32-bit data blocks. Consider a stream of 352 32-bit datablocks B0, B1, B2, . . . B351 emerging from the parity generator fortransmission. Recall that the 24 DSD channel frame of FIG. 18B comprisesan audio data payload of 352 32-bit data blocks. The resulting stream ofnibbles from the interleaver is comprised as shown in FIG. 24. In thisFigure the bits of the audio payload are labelled such that B2[0] refersto bit 0 of block 2, for example. Thus it can be seen that nibble zerocomprises bit 0 of blocks 0, 1, 2 and 3 respectively; nibble 1 comprisesbit 0 of blocks 4, 5, 6 and 7 respectively and so on. Accordingly,nibbles 0 to 7 collectively comprise bit 0 of each of the thirty-two32-bit data blocks, nibbles 8 to 15 collectively comprise bit 1 of eachof the thirty-two 32-bit data blocks and nibbles 2802 to 2815 comprisebit 31 of each of the thirty-two 32-bit data blocks. The 32-blockinterleaving system used by MAC-DSD facilitates the correction of up toeight symbol errors (i.e. 32 bits can be corrected overall) in a groupof 32 interleaved data blocks (256 nibbles or symbols).

In summary, the version of the MAC-DSD protocol used for transmission of24 DSD channels as described above with reference to FIGS. 18B and 20 to23 has key features including: 24-channel, full-duplex transfer of2.8224 MHz DSD audio; 100Base-TX physical layer; audio latency of lessthan 50 microseconds; Hamming linear block code error correction, with256-nibble interleaving, to correct up to 8 nibble errors per 256-nibbleblock group; 64 fs DSD clock transfer in both directions; and frame flagindication for transfer of the 44.1 kHz sync signal.

FIG. 25 schematically illustrates the protocol layers of the MAC-DSDprotocol for the particular example embodiment using the 24 DSD channelframe format. On the transmitter side 1000 the protocol layers comprisea parity generating and formatting layer 1010 that receives the incoming24 channel DSD audio stream and an auxiliary data stream of up to 5.6Mbit/s. This layer 1010 generates six parity bits for each 24 audio bitand 2 auxiliary bit sample and formats the resulting 32-bit data block.The 32-bit data blocks output by the parity generating and formattinglayer 1010 are supplied to an interleaving layer 1020 that interleavesthe data blocks in groups of 32 and outputs the interleaved data acrossthe MII 218 in 4-bit nibbles as specified in FIG. 24. The nibbles ofdata from the interleaver are supplied to the FIFO buffer 810 of thetransmitter at a continuous data rate of 90.3168 Mbit/s. The nibblescontinue to fill the FIFO buffer 810 until the predetermined thresholdbuffer occupation level is reached (as described with reference to FIG.14) whereupon assembly of a data frame begins. During data frameassembly data nibbles are read out of the FIFO buffer 810 and passed toa frame assembly layer 1040. The frame assembly process involves use ofa header data generation module 1050 that generates frame headerinformation and a CRC generation module 1060 that generates data for theCRC field, which is word 367 of the frame format of FIG. 18B. The framesare assembled such that they contain a 1408 byte payload of 352 DSDsamples contained in 352 32-bit data blocks. Data from the frameassembly layer 1040 is output as MII frames (which comprise nibbles) ata rate of 101.6064 Mbit/sec and supplied to the transmitter physicallayer 1070 which prepares the data for transmission across the physicalmedium. The transmitter physical layer 1070 forms a 5-bit symbol fromeach 4-bit nibble and the symbols are transmitted to the receiver acrossa twisted-pair cable. On the receiver side 1100 a receiver physicallayer 1110 receives the 5-bit symbols and processes them to form MIIframes comprising 4-bit nibbles. The MII frames are supplied to a framedisassembling layer 1120 at a rate of 101.6064 Mbit/sec, which performsthe CRC checks and strips off the header data for subsequent processing.The frame payload is output by the frame disassembling layer 1120 as MIInibbles which are fed to the FIFO buffer 870 (as described above withreference to FIG. 15) which has a low latency with regard to dataoutput. Data is output from the FIFO buffer 870 in the form of MIInibbles and passed to a deinterleaving layer 1160. The de-interleaverde-interleaves the data in groups of 32 data blocks to reconstructindividual 32-bit data blocks of the format illustrated in FIG. 22. The32-bit data blocks are then passed to a parity decoding and dataextraction layer 1170 whereupon the parity data is used to perform errorcontrol and the recovered payload data is extracted. The output of thislayer is a 24 channel DSD audio stream and an auxiliary data stream ofup to 5.6 Mbit·s Note that in FIG. 25, although the FIFO buffers 810,870 do not perform any data translation and therefore are nottechnically protocol layers, they are included in the schematicillustration of the protocol layer structure for completeness.

Note that in the case of the 352 sample payload of the 24 DSD channelframe format of FIG. 18B, the transmission buffer size and predeterminedbuffer occupancy threshold differs from the buffer size and occupancythreshold specified in the description of FIG. 14 above for the 370sample payload of the 32 DSD channel Frame Format of FIG. 18A. Inparticular, for the 24 DSD channel frame format the minimum buffer sizeis 36 data blocks (rather than 42 data blocks) and the correspondingminimum occupancy threshold value is 30 data blocks (as before). Theaudio latency introduced by this buffering is equivalent to 36 DSDsamples (rather than 42 samples) or 14.9 microseconds (rather than 12.2microseconds).

The above described system in which the physical layer of a link such asan Ethernet link is used to provide a data communication system fortransmission of DSD data may also be used to transmitted other types ofclocked digital data. In particular the system may be adapted toaccommodate transmission of Pulse Code Modulated (PCM) digital data. Thephysical layer connection according to the present technique offers highbandwidth for communication of PCM data.

PCM data is clocked at a much lower frequency (e.g. 44.1 kHz-96 kHz)than the 64 Fs clocking frequency of DSD data. Accordingly, in order tosupport PCM transmission as well as DSD transmission a further lowerfrequency clock signal, which shall be referred to as the word clocksignal, is communicated between networked devices along the twisted paircable. The word clock is used for reproduction of PCM data at thereceiver. The frame format for 24 DSD channels as illustrated in FIG.18B allows for transmission of 352 bits of data per frame for each of 24audio channels. Essentially, 352 24 bit DSD samples (one bit perchannel) are transmitted in a single frame. Data blocks are transferredover the link at an aggregate rate of 64 Fs, that is, 2.8224 MHz(=64*44.1 KHz) for 44.1 kHz based audio and 3.072 MHz for 48 kHz basedaudio. In order to transfer PCM data in the desired frequency range of(44.1 kHz-12.5%) to (96 kHz+12.5%) at the required data rates it isnecessary to accommodate between 4 and 13 24-bit samples per frame.Accordingly, a number of alternative data formats are defined so that atthe transmitter it is decided how many samples should be sent in thenext frame and a look-up-table is consulted to select the appropriateone of the alternative data formats. Known PCM transmission formats suchas I2S and AES3-1992 and package PCM sample data in serial sub-frames.AES3 is an Audio Engineering Society standard for the serialtransmission format for linearly represented digital audio data overconventional shielded twisted-pair conductors, of up to at least 100 min length, without equalisation. FIG. 26A schematically illustrates theAES3 sub-frame format. Each AES3 frame is uniquely composed of twosub-frames and typically the rate of frame transmission correspondsexactly to the source sampling frequency. The first sub-frame startswith the pre-amble X but the preamble changes to Z once every 192frames. This defines the block structure used to organise the channelstatus information. The second sub-frame always starts with preamble Y.As illustrated in FIG. 26A each AES sub-frame is 32-bits long in which:bits 0 to 3 contain a preamble; bits 4 (least significant bit) to 27(most significant bit) contain a 24-bit audio sample word; bit 28 is a“V” field which carries a validity bit associated with the audio sampleword; bit 29 is a “U” field which contains one bit of a user datachannel associated with the audio data channel transmitted in the samesubframe; bit 30 is a “C” field or channel status field which carriesone bit of channel status information associated with audio datatransmitted in the same subframe; and bit 31 is a “P” field whichcarries a parity bit such that time slots 4 to 31 inclusive will carryand even number of ones and an even number of zeros i.e. even parity.The V bit is logic 0 if the audio sample word is suitable for conversionto an analogue audio signal and is logic 1 otherwise. The C bit isone-bit of channel status information specifying for example the lengthof audio sample words, number of audio channels, sampling frequency etc.Channel status information is organised in 192-bit blocks sub-dividedinto 24 bytes. The first bit of each block is carried in the framehaving preamble Z.

FIG. 26B schematically illustrates the sub-frame format for PCMtransmission according to the present technique. This 27-bit sub-framestructure includes the U bit and C bit fields of the known AES3sub-frame format to facilitate transparent transfer of AES3 format dataacross the physical layer link. As illustrated in FIG. 26B, bits 0 to 23contain data, bit 24 contains the U bit, bit 25 contains the C bit andbit 26 contains an M bit. The U and C bits are taken directly fromincoming AES3 data streams or from the user data and channel statusbuffer memory in the transmitter. The M-bit is a multiplexed bitspecific to the present technique and may be used to contain any of thethree following indications at certain points in the bitstream: an S bitwhich is a flag that identifies an external Fs/n (n integer)synchronised data sample and is repeated across all data channels everyn periods of Fs; the Z bit that signals the start of the AES3 U/C datablock which repeats on each channel every 192 samples; and the V bitwhich is the sub-sampled AES3 V-bit status. The S and Z indications areeach used to identify particular samples within the audio data stream.Since the S and Z indications are by their nature periodic it should inprinciple be sufficient to simply specify their phase with respect tothe sample clock. However, in practice the S and Z indications should berepeated moderately frequently to enable the link to lock rapidly onstart-up and to detect any link failures in a timely manner. The M-bitmarks an S indication with two consecutive logical 1's in the bitstreamas shown in FIG. 27B whereas a Z indication is marked by a singlelogical ‘1’ as shown in FIG. 27A. In order to indicate the sync sample(S-bit) by two consecutive logical ‘1’s in the M bit data stream acounter is provided at the transmitter to pre-empt the occurrence of thesync signal. The V-bit status is indicated for each channel in the bitimmediately following the S indication. This implies that V is indicatedless frequently than per-sample, but is indicated per-channel atintervals of the S sync (i.e. typically Fs/2048, or about 46 ms at 44.1kHz), and also assumes that V-bit status does not change rapidly, whichis a reasonable assumption for the vast majority of audio applications.FIG. 27C shows a V-bit indication which is a logical 1 (true), therebysignalling that channel samples are valid resulting in three consecutivelogical 1's in the bit stream (two 1's for the S-bit and 1 for theV-bit). FIG. 27D shows a V-bit indication of 0 (false) immediatelyfollowing the two logical 1's of the S-bit. This signals that thechannel samples are invalid. Since the M-bit is used to indicate anumber of alternative events it is likely that event indications willeither coincide or be close enough in succession to interfere. For thisreason priority is always given to S indications over Z indications. Asa consequence of this Z indications will occasionally be missed so it isappropriate to maintain counts of the U/C block phases in the receiverin order to set the Z-bits in outgoing AES3 streams in thesecircumstances. FIGS. 28A to 28E give examples of relative occurrences ofS indications and Z indications and indicate whether or not the relativepositioning requires that the Z indication be disabled. In FIG. 28A theZ indication coincides with the second bit of the S indication so Z isdisabled and only S is indicated. In FIG. 28B the Z indicationimmediately precedes the S indication in the received M-bit sequence, inwhich case Z is disabled because S is imminent. Otherwise the threeconsecutive logical 1's would be indistinguishable from the S and Vindication of FIG. 27C. In FIG. 28C the Z indication precedes the Sindication but is separated from it by a single bit period. Since Z andS are sufficiently separated so that they do not interfere so both the Zindication and the S indication are enabled here. In FIG. 28D the Zindication immediately follows the S indication and could lead toambiguity so the Z indication is disabled. In FIG. 28D, the Z indicationfollows the S indication with a single bit-period separation. As forFIG. 28C, Z and S are sufficiently separated so that they do notinterfere so both the Z indication and the S indication are enabledhere.

For the purposes of transferring PCM data between devices on thephysical layer the frame format is basically the same as the formatdescribed above in relation to FIG. 18B. In particular, each frame is1472 bytes long and the data payload consists of 352 32-bit data blocks.Each 32-bit block comprises 24 audio data bits and two auxiliary databits, which together form 26 independent bit-stream segments of 352 bitsper frame. In PCM mode, each of the 24 audio bitstreams is divided intoa number of sample subframes which are separated by padding. The numberof subframes varies from 4 to 13 in dependence upon the particular PCMsample frequency. This enables support for samples rates from 44.1kHz−12.5% to 96 kHz+12.5%. Each sample sub-frame contains data from asingle PCM sample.

For each possible number of sample subframes per bitstream segment, aspecific arrangement of sample subframes and padding bits is defined.All padding bits should have the value 0. This determinism enables thereceiver to correctly extract the sample subframes from the bitstreamsegment. These arrangements are shown in Table 9A. Table 9B gives aspecific example of the subframe arrangement for the case of 9 samplesubframes per frame. TABLE 9A Final padding bits at end of Number ofsample Padding bits after bitstream subframes each subframes segment  912  1 10 8 2 11 5 0 12 2 4 13 0 1

TABLE 9B Element Bits sample subframe 1 of 9, bit 0 first 27 padding 12sample subframe 2 of 9, bit 0 first 27 padding 12 sample subframe 3 of9, bit 0 first 27 padding 12 sample subframe 4 of 9, bit 0 first 27padding 12 sample subframe 5 of 9, bit 0 first 27 padding 12 samplesubframe 6 of 9, bit 0 first 27 padding 12 sample subframe 7 of 9, bit 0first 27 padding 12 sample subframe 8 of 9, bit 0 first 27 padding 12sample subframe 9 of 9, bit 0 first 27 padding 12 final padding  1 Total352 

Accordingly, the data block audio bit usage for the frame format of FIG.18B in PCM mode differs from the audio bit usage in DSD mode. A furtherdifference in the frame format in PCM mode relative to DSD mode relatesto the Frame Format ID values contained in the three identical frame IDsections in words 13 and 14 of FIG. 18B. The frame format ID fields ofeach section were outlined above with reference to FIG. 20. In summary,each frame format ID section comprises a flags field, a frame typefield, a protocol major version field and a protocol minor versionfield. To accommodate PCM mode, the frame type field values are extendedrelative to those defined in Table 6 above. As specified in the table ofFIG. 29, 10 new frame type values have been defined corresponding to the10 different possibilities

-   -   (integers in the range 4 to 13) for the number of sample        subframes per frame. Two separate formats for the frame flags        field of the frame format ID (see words 13 and 14 of FIG. 18B        and FIG. 20) have been defined: one format for DSD frames and        another format for PCM frames. The table of FIG. 30 shows the        flags field format for a DSD frame. In this case flag bit 0        indicates whether or not the first DSD sample in the frame was        received simultaneously with the 44.1 kHz sync clock positive        edge whereas flag bit 1 indicates whether or not the first DSD        sample in the frame was received simultaneously with the Fs/n        sync clock positive edge. The tables of FIG. 31 show the flags        field format for a PCM frame. In this case flag bits 0:1 specify        the frequency of the audio base clock whereas flag bits 3:2        specify the base clock sample rate multiplier. The sample rate        can be specified to be 1, 2, 4 or 8 times the base clock        frequency Fs.

The PMC frame format described above relate to an example embodiment inwhich 24 audio channels are accommodated. An alternative embodiment mayinvolve accommodating 48 audio channels in IFs PCM mode (sample rate44.1 kHz or 48 kHz+12.5%). In this case two audio channels aremultiplexed onto each bitstream. The multiplexing may be implemented persub-frame or per bit. The clock and synchronisation functions of the PCMmode will now be considered in detail. As mentioned above, fortransmission of PCM data across the network a word clock is required inaddition to the 64 Fs MAC-DSD cable clock. Rather than sending twoseparate clock signals across the twisted pair cable, the 64 Fs clockand the word clock are multiplexed. The multiplexing process involvesmodulating the word clock signal onto the 64 Fs clock signal by shiftingat least one edge of the 64 Fs clock pulse i.e. by generating a “clockpulse width deviation”. The clock pulse width deviation acts as a phaseindicator signal for the word clock, which is embedded in the 64 Fsclock. The clock pulse width deviation is formed by identifying certaintransitions in the 64 Fs clock signal which are determined to becoincident with the word clock transitions at the transmitter. Since inthis embodiment the positive-going transitions of the 64 Fs clock areused for timing synchronisation, the phase of the word clock is encodedby shifting the positions of negative-going 64 Fs clock transitions. Inparticular, where a word clock and 64 Fs clock transitionspositive-going transition coincide, the preceding negative-goingtransition of the 64 Fs clock is shifted to produce a multiplexed clocksignal. FIG. 32 schematically illustrates how the multiplexed clocksignal is formed in dependence upon the 64 Fs signal and the word clocksignal. In FIG. 32 the uppermost signal 3210 is the unmodified 64 fsclock signal used to synchronise the PLL in the receiver, the middlesignal 3220 is the word clock signal used to synchronise PCM dataframing in the receiver and the lowermost signal 3230 is the multiplexedclock signal in which the negative-going transitions have been shifted.The multiplexed clock signal 3230 is the clock signal that istransferred over the MAC-DSD link. In FIG. 32 time is increasing to theright along the horizontal axis. It can be seen that the positive goingedge 3212 of the 64 Fs clock signal coincides with the positive-goingedge 3222 of the word clock signal. Accordingly, the precedingnegative-going edge 3214 of the 64 fs clock signal has been shifted backin time by time t_(clkmod) thereby reducing the width of that clockpulse (see edge 3234 of in the multiplexed clock signal 3230) whilst thesubsequent negative-going transition 3216 of the 64 fs clock edge hasbeen shifted forwards in time by a corresponding time incrementt_(clkmod) (see edge 3236 of the multiplexed clock signal 3230) therebyincreasing the width of the pulse. The negative transition 3236 afterthe word clock edge 3222 is delayed by the same amount that thepreceding negative edge 3234 is advanced. The delay of the subsequentnegative-going transition 3236 is performed by way of compensation toavoid DC content in the signal. DC content in the signal is likely tocause periodic “baseline shift” at the word clock frequency, when thesignal is transmitted in an AC-coupled system. Performing thiscompensation on the clock cycle following the coincidence of the wordclock and 64 Fs clock also reduces the Fs/n clock frequency content inthe 64 fs signal. This is important, since it is desirable to reducelow-frequency jitter in the received 64 fs clock, which is typicallyused to feed a PLL circuit to generate an ADC/DAC audio sample clock.The edge offset time (t_(clkmod)) shown in FIG. 32 is exaggerated forease of illustration. The true time shift will typically be very small,for example, one 2048 fs period (11.07 ns, at Fs=44.1 kHz). Note thatthe shift or “pulse width deviation” introduced to the clock mux signalshown in FIG. 32 does not occur every word clock cycle. Rather the clockpulse width deviation only occurs once every n clk_fs cycles, where n isan integer value controlled by a register. Effectively, introduction ofthe clock pulse width deviation every n word clock cycles amounts tomultiplexing a clock signal of frequency Fs/n with the 64 fs clock.Since the frequency of the sample clock (word clock) is known, all thatneeds to be communicated by the transmitter is phase information whichenables the receiver to reconstitute the word clock signal with asix-bit counter. The counter is reset by the Fs/n signal and incrementedby the 64 fs clock. Note that the signal forms of FIG. 32 apply to boththe transmitter (which generates the multiplexed clock) and receiver(which generates the Fs clock) ends of the connection.

FIG. 34 schematically illustrates a MAC DSD transmitter 3400 (thecounterpart of the FPGA 512 in FIG. 6) adapted for transmission of bothPCM and DSD data. The MAC DSD transmitter module comprises: a 64 Fsclock generator 3410; an Fs sync generator (word clock generator) 3420;a clock multiplexer module 3430, a counter 3440; an S-bit generator3450; an encoding and block construction module 3460; an interleaver3470; a FIFO buffer 3490 and a frame assembler 3492.

The clock multiplexer 3430 generates the pulse width deviated clocksignal (illustrated in FIG. 32) by shifting certain negative-going edgesof the 64 Fs clock signal in dependence upon output from the word clocksync generator 3420. The pulse width deviated clock signal istransmitted across the twisted pair cable to the receiver. The counter3440, keeps track of the 64 fs clock signal in order to pre-empt theoccurrence of the Fs sync signal. It is necessary to pre-empt the Fssync signal to facilitate generation of the S-bit in the audio datastream, which is performed by the S-bit generator module 3450. Note thatthe PCM samples are individually labelled with sync markers via theM-bit encoding (see 27-bit PCM audio sample structure of FIG. 27)whereas DSD mode frames rely on a frame flag bit being set in thetransmitter and the marker bit of the first sample of the flagged framebeing set on entry to the receiver FIFO. The output of the S-bitgeneration module 3450 is supplied to the encoding and blockconstruction module where parity bits are generated and padding bits areinserted for PCM mode frames only to construct the 32-bit data blocks ofthe frame payload (see FIG. 18B). Data blocks from the encoding andblock construction module 3460 are supplied to the interleaver 3470which outputs 4-bit nibbles of interleaved data to the FIFO buffer 3490.The transmitter FIFO 3490 bridges the audio clock and link clock (PHY514 in FIG. 6) domains of the transmitter. The transmitter FIFO buffer3490 is 25 bits wide. Of the 25 bits, 24 bits are associated with 24respective channels of concurrent DSD or PCM audio samples, the 25th bitbeing reserved as a synchronisation marker. The 25^(th) bit indicateswhether the corresponding DSD or PCM audio sample occurredsimultaneously with an Fs/n clock edge in the transmitter. This isillustrated in FIG. 33 which shows five consecutive DSD samples (n−2),(n−2), n, (n+1), (n+2) and their timing relationship with the local 64Fs clock and the word clock. It can be seen that sample n corresponds intime to the coincidence of the positive going edge of the word clock and64 Fs clock. Accordingly the positive-going edge of the marker bitcoincides with the beginning of DSD sample n. Data is read out from thetransmitter FIFO 3490 in dependence upon the occupancy threshold (asdescribed above with reference to FIG. 14) and supplied to the frameassembler 3492. Data from the frame assembler 3492 is supplied to thePHY of the transmitter. The transmitter start-up procedure differsslightly for PCM mode and DSD mode operations. In PCM mode on start-up,the transmitter starts transmitting as soon as possible. Marked samplesare explicitly indicated via the PCM sample subframe ‘M-bit’ encoding.However in DSD mode marked samples are not explicitly indicated but arederived from flag bit 1 of the frame flags as specified in the table ofFIG. 30. Accordingly, on start-up in DSD mode, the transmitter holds-offtransmitting the first frame until one of the marked samples (i.e.sample synchronous with Fs/n clock) is available in the FIFO. While thetransmitter is in this hold-off state, samples are read-out of the PHYclock side of the FIFO and dropped. When a marked sample becomesavailable (as indicated by flag bit 1), the interleaving, encoding andframe formatting mechanisms are enabled, such that the first sample inthe first frame is the marked sample. From this point, frametransmission is governed by the buffer status (to initiate frameassembly) and frame format rules.

FIG. 35 schematically illustrates a MAC DSD receiver 3500 (thecounterpart of the FPGA 526 in FIG. 7) adapted for reception of both PCMand DSD data. The MAC-DSD receiver 3500 comprises: an Fs/n syncdetection module 3510; an Fs clock generation module 3520; a monostablecounter 3530; a frame receiving and decoding module 3540; a FIFO buffer3550; a deinterleaver 3560; and a decode/block deconstruction module3570. The Fs/n sync detection module receives the pulse width deviatedclock signal from the twisted pair cable and determines the relativephases of the 64 fs clock and the word clock on the basis of thissignal. The Fs/n phase information is supplied as input to the wordclock generation module 3520, which outputs the word clock (Fs) signal.

The incoming cable clock signal is passed directly to the local phaselocked loop of the receiver system in order to synchronise the system.It is not possible to use the extracted Fs clock derived from the wordclock generation module 3520 for this purpose. This is because the wordclock generation module 3520 requires sequential logic that is clockedform the local PLL so that the extracted signal is always synchronouswit the local PLL. This means that the output of the word clockgeneration module 3520 is unsuitable as a synchronisation source for thePLL.

Note that the Fs clock signal in the receiver is of the same phase asthe Fs clock signal in the transmitter as a result of the Fs/n sync. TheFs/n phase information is also supplied to the monostable counter. Themonostable counter is triggered by reception of each Fs/n indication tocount 64 fs clock periods. The FIFO output is disabled on detection ofthe first marked sample in the FIFO 3550, whereupon the FIFO begins tofill with data. After a number of 64 fs cycles equal to thepredetermined link latency, the FIFO 3550 outputs are enabled. Thepredetermined link latency incorporates the delay incurred in thetransmitter due to data encoding and frame assembly plus the delayincurred at the receiver due to the decoding process. The predeterminedlatency of the data link is programmed to be an exact multiple of 64 fsclock periods measured with respect to the Fs/n sync signal transmittedon the cable clock.

MII frames (comprising nibbles) from the PHY 526 of the receiver (seeFIG. 7) are supplied as input to the frame reception and decodingmodule, where header data is removed, and error checks are performed.The decoded data is supplied as input to the FIFO 3550 in the form ofMII nibbles. The FIFO outputs 4-bit data nibbles, which are supplied tothe deinterleaver 3560 for deinterleaving. The deinterleaved data isthen fed to the decode/block deconstruction module 3570 where the audiodata payload data is extracted and output as an audio data stream.

FIG. 36 schematically illustrates a system in which twosample-synchronous links are operated in parallel and in which the Fs/nsync signal is used to synchronise the parallel links. The systemcomprises a transmitting device 3600 which is connected by a firstcables 3603 and a second cable 3605 to a receiving device. Thetransmitting device 3600 has a first MAC-DSD transmitter 3610 which isconnected to a first MAC-DSD receiver 3710 in the receiving device 3700via the first cable 3603. The transmitting device 3600 also has a secondMAC-DSD transmitter 3620 which is connected to a second MAC-DSD receiver3720 in the receiving device 3700 via the second cable 3603. The twoMAC-DSD transmitters 3620, 3620 are driven by an internal clock source3630 that supplies them with both a 64 Fs clock and a word clock. In thereceiving device 3700 only the first MAC-DSD receiver 3710 acts as aclock source thereby serving as a master clock. This receiver 3710derives the word clock signal and the 64 Fs clock signal from themultiplexed clock signal received via the first cable 3603. Note that ifa separate word clock source were used then neither of the MAC-DSDreceivers 3710, 3720 would serve as a master clock source. The 64 Fs andword clocks extracted from the link cable 3603 are supplied to a PLL3730 that outputs a word clock signal and a 64 Fs clock signal to boththe first MAC-DSD receiver 3710 and the second MAC-DSD receiver 3720.The second MAC-DSD receiver 3720, which is not serving as the masterclock source, should re-clock the multiplexed clock signal received viathe second cable 3605 in order to detect the Fs/n indicator (i.e. theclock pulse width deviation). The propagation delay on the link via thefirst cable 3603, is likely to be different from the propagation delayon the link via the second cable 3605. The difference in propagationdelay between the first link 3603 and the second link 3605 is determinedby comparing the position of the received 64 fs clock edges with thelocally-regenerated 64 fs clock (from PLL 3730), and by comparing theposition of the received Fs/n indicator with the locally-regenerated Fsword clock, (also from PLL 3730). FIG. 37 schematically illustrates ameasured difference in propagation delay between the two links. It canbe seen from FIG. 37 that the positive-going clock edge 3812 immediatelyfollowing the shifted negative-going clock edge (pulse width deviatedpulse) in the clock multiplexed signal 3810 is shifted relative to thecorresponding positive-going clock edge of the locally regenerated 64 Fsclock signal 3822 and relative to the positive edge 3832 of the locallyregenerated word clock signal 3830 by an amount t_(offset). Inparticular, the received cable clock Fs/n indicator occurs later in timethan the local Fs clock edge. Given that the local Fs clock edge isderived to be synchronous with the received cable clock Fs/n indicatoron the clock master MAC-DSD link, this indicates that the cablepropagation delay for the second link 3605 is longer than the cablepropagation delay for the clock master link 3603. The relativedifference in propagation delay between the clock master link 3603 andthe other link 3605 is t_(offset). The time t_(offset) is defined to benegative in the case that the non-master link 3605 is delayed relativeto the clock master link 3603 as shown above, and positive in the casethat the non-master link 3605 is advanced relative to the clock masterlink.

Once t_(offset) is determined at the receiver, the following algorithmmust be followed to adapt the latency monostable counter 3530 of thereceiver to ensure synchronous operation with the clock master link. Ift_(offset) is positive (i.e. non-master link 3605 is advanced in timerelative to clock master 3603 link) then when the Fs/n indicator isdetected via link 3605 the latency monostable counter in MAC_DSDreceiver 3720 is not started until the next word clock edge. However, ift_(offset) is negative (i.e. non-master link 3605 is delayed relative tomaster link 3603 as in FIG. 37) t_(offset) is rounded down to an integernumber of 64 fs periods and one is subtracted from this value to derivea value for the timeout for the non-master latency monostable counter.The latency monostable counter in MAC-DSD 3720 (non-master) is startedat the first 64 Fs clock edge following the timeout. This will result inthe non-master latency monostable counter timing out synchronously withthe monostable counter in the clock master receiver.

If the predetermined link latency period expires before a marked sampleis detected in the FIFO 3550 this is an indication that either there isa fault in the system or that the predetermined link latency has beenset at too small a value for the link conditions. Accordingly, if thelatency period expires before the marked sample is detected an interruptsignal is raised and error indicator bits are set. Table 10 belowspecifies for each of seven audio data formats an example link latencyin 64 Fs periods and in microseconds. TABLE 10 Audio format Latency(64fs periods) Latency (μs) DSD 127 44.9  44.1 kHz PCM 192 (3 samples)68   48 kHz PCM 192 (3 samples) 62.5  88.2 kHz PCM 160 (5 samples) 56.6  96 kHz PCM 160 (5 samples) 52.1 176.4 kHz PCM 144 (9 samples) 51.0  192 kHz PCM 144 (9 samples) 46.9

FIG. 38 is a schematic diagram showing auxiliary data routing by aMAC-DSD router 4030.

The router comprises a number of MAC-DSD transceivers 4000, each ofwhich is arranged as described above to transmit auxiliary data andaudio data via an Ethernet physical layer device, and, on receiving sucha bit stream, to separate out the audio data and auxiliary data streams.It should be noted that audio data routing and handling is not shown inFIG. 38.

In order to transmit auxiliary data over this system, the auxiliary datais formatted into Ethernet-like packets and the packets are thenmultiplexed into the two auxiliary data channels in the MAC-DSDprotocol.

Non-limiting examples of the types of auxiliary data that might becarried are remote control data for recording and playback functions;general remote control data for audio and video devices; timecode; mediacontent metadata; and auxiliary media, such as streamed compressed videoimages to accompany an audio feed for audio-visual production.

When a bit stream is received by one of the transceivers 4000, theauxiliary data bit stream is separated out and supplied to an auxiliarydata bit stream-RMII interface 4010. RMII stands for Reduced MediaIndependent Interface, and is established as a standard arrangementwithin Ethernet systems, but it will be appreciated that otherinterfaces such as MII (media independent interface), SMII (serial mediaindependent interface) and SS-SMII (source-synchronous serial mediaindependent interface), which are all widely supported and used inmulti-channel Ethernet PHY interfaces, could be used. The functionalityof all of these is broadly equivalent; they just offer differenttrade-offs in pin-count reduction versus logic complexity.

As described above, the auxiliary data is carried as periodic singlebits, or small groups of bits, interspersed amongst the audio data bits.

The RMII interface 4010 converts the auxiliary data bit stream from thetwo channels within the MAC-DSD protocol back into data packets whichare set up so as to mimic Ethernet protocol data packets. The datapackets have a packet address specifying another one of the MAC-DSDtransceivers (or, in the case of a “broadcast” message, all of them).

The pseudo-Ethernet packets are supplied to a conventional Ethernetswitch circuit 4020 which effects the routing on the basis of the packetaddresses. In accordance with that routing, the packets are passed backto the auxiliary bit stream-RMII interface 4010 to be formatted backinto an auxiliary data channel format for carriage by the appropriateMAC-DSD channel. From the interface 4010 the auxiliary data is passed tothe appropriate one(s) of the transceivers 4000.

FIG. 39 is a schematic diagram showing a protocol by which the auxiliarydata is carried.

At the bottom of FIG. 39 there is shown the Ethernet physical interfacelayer (PHY). This layer is common between the protocol shown in FIG. 39and a standard Ethernet protocol. Physical layer data frames areprefixed only by a preamble.

On top of the physical layer there is imposed the MAC-DSD frame formatmade up of 1448-byte frames as described above. Over this, the payloadencoding provides twenty-six 64 Fs channels (bit streams) with forwarderror correction and interleaving. It will be clear that the choice ofthe number of such channels is merely an implementation detail.

Again, as described above, the payload can include an audio bit stream,for example in DSD or PCM format and an auxiliary data bit stream. Inthe case of the auxiliary data, 512-byte frames are demarcated in thecontinuous 128 Fs bit stream forming the two auxiliary data channels.Within those 512-byte frames, there is defined an Ethernet data frameformat. (512 bytes is just an example frame length used in a firstimplementation. Other implementations can use different frame lengths,at least up to 1536 bytes, which is the maximum frame length forconventional Ethernet transmission).

So, the system carries frames which, when separated out from the rest ofthe physical bit stream, appear to be Ethernet auxiliary data frames.However, they are not carried by a conventional Ethernet protocol, butinstead are carried by being inserted into the 128 Fs bit stream formingthe two auxiliary data channels. So, the pseudo-Ethernet frames aretransmitted as successive auxiliary data bits interspersed within anaudio data bit stream. They would not be directly recognisable asEthernet frames by a conventional Ethernet data handling device.

FIG. 40 schematically illustrates a data structure of an auxiliary dataframe. The structure comprises a fixed header 4040, a destinationaddress 4050, a length field 4060, a payload 4070 and an error detectingcode 4080. The total length of the frame in this embodiment is a maximumof 128 words, which equates to 512 8-bit bytes.

FIG. 41 schematically illustrates the operation of the interface 4010and the switch 4020 of FIG. 38 in a data receiving mode.

The 128 Fs auxiliary data bit stream, comprising the two logicalchannels of auxiliary data separated out by the MAC-DSD transceiver4000, is supplied to a frame identifier 4100. Frames are identified inthe auxiliary data stream by a synchronisation flag comprising01111111110 (a zero, nine ones, a zero). The frame is then transmittedserially. To ensure the uniqueness of the synchronisation flag, a zerois inserted (on transmission) after any eight consecutive ones of theframe data—so the occurrence of nine consecutive ones can only indicatea synchronisation flag. The extra zero is inserted irrespective of thebit following the run eight ones. At the end of the frame, anothersynchronisation flag is transmitted. During intervals when a frame isnot being transmitted, the bit stream comprises contiguoussynchronisation flags.

Therefore, at the frame identifier 4100, incoming data is examined todetect the presence of nine consecutive ones, thereby indicating a framesynchronisation flag.

The data is then passed to a descrambler 4110. To put the descramblerinto context, the reason for scrambling the data in the first place willnow be described.

Certain data payloads which feature frequent long strings of ones couldcause the system to insert large numbers of additional zeros, with acorrespondingly large increase in the amount of data to be sent. This inturn could cause a very non-deterministic reduction in the effectivebandwidth of the system. This may be mitigated by scrambling the datawith a convolutional encoder before the bit stuffing (insertion of extrazeroes) is carried out. In this case, the expansion from the insertionof extra zeroes will be reduced to a factor of approximately 1/(2⁸) (1bit in 256, or 0.39%).

The scrambling encoder is schematically illustrated in FIG. 43 and thecorresponding decoder in FIG. 44.

The encoder contains a 9-bit shift register and XOR gates, so that withan input V and an output W it implements:W=V*W ⁻⁵ *W ⁻⁹

The descrambling circuit of FIG. 44 again comprises a nine bit-shiftregister and XOR gates, so that with an input Y and an output Z itimplements:Z=Y*Y ⁻⁵ *Y ⁻⁹

Note that neither the scrambler nor the descrambler imposes a delay uponthe signal. Thus a cascade of the scrambler and descrambler imposes noalgorithmic delay.

Therefore, at the descrambler 4110 (returning to FIG. 41) any additionalzeroes (i.e. a zero after a run of eight ones) are first removed andthen the data is descrambled using the descrambler of FIG. 44.

The resulting descrambled data is then passed to a dual port randomaccess memory (DPRAM) 4120. This contains two storage areas, each largeenough to hold at least a single data packet. Data is written into onestorage area while it is being read out of the other, and then viceversa. When substantially all of a packet has been loaded into one sideof the DPRAM, and assuming that the channel protocol allows it at thatinstant (see below), the packet of data is read out by an RMII interface4130. The data is passed from the RMII interface 4130 to the Ethernetswitch circuit 4020. The way in which this is achieved will be describedbelow.

Referring to FIG. 42, when a data packet is received by the RMIIinterface from the Ethernet switch chip 4020, it is stored in a furtherDPRAM 4200. As a packet of data is assembled in the DPRAM 4200, it ispassed to a scrambler (as FIG. 43) which includes a bit stuffer to add azero after a run of eight ones in the scrambled data stream, and fromthere to a frame marker 4220 which inserts the frame synchronisationcode 01111111110. The resulting bitstream is then transmitted within theauxiliary data channels of a MAC-DSD link.

The Ethernet switch chip 4020 and the RMII interface 4130 both operateunder the control of an RMII interface synchronisation signal, forexample a clock source 4140 running at 50 MHz. In other embodiments,however, the implementation may be simplified by running the RMIIinterface and the Ethernet switch chip at a non-standard rate such as aclock rate synchronous with the audio master clock. In such arrangementsthe clock source 4140 would be replaced by a clock generator receivingas an input the 64 Fs clock signal (or a signal related to it) shown in,for example, FIGS. 6 to 10 above.

The transmission protocol used between the RMII interface 4130 and theEthernet switch circuit 4020 is the so called 100 Base-T half duplexsystem. This is a 100 Mbit/s arrangement in which only one of theparties to the communication can transmit at any one time. So, althoughthe transmission can be bi-directional (to or from the Ethernet switchcircuit 4020), the data transfer can occur in only one of the twodirections at any one instant. The reason that the 100 Base-T halfduplex system is used will now been explained.

The incoming data rate from the MAC-DSD transceiver (as received by theframe identifier 4100) is 128 Fs, or about 5.6 Mbit/s. This is thereforethe maximum speed at which data packets need to be transmitted from theRMII interface 4130 to the Ethernet switch chip 4020. It is also themaximum speed at which data can be sent from the Ethernet switch chip tothe RMII interface for retransmission via a MAC-DSD transceiver 4000.But in a system having several nodes connected via a single router, itis quite possible that multiple packets could be routed to a singleoutput MAC-DSD channel at a certain time. This could in principle meanthat the Ethernet switch chip might attempt to send data to a singleRMII interface at a data rate greater than 5.6 Mbit/s.

The Ethernet switch chip 4020 is a standard Ethernet device. This isconsidered desirable because such devices are cheap and they containlogic for avoiding various types of transmission or reception faults.However, a 100 Base-T Ethernet switch chip does not contain logic fordealing with an output channel limited to a streamed data rate of 5.6Mbit/s.

So, to avoid this problem happening, it is important that the RMIIinterface can regulate the flow of data which it receives from theEthernet switch chip 4020. This is carried out using the half duplexarrangement.

In basic terms, an RMII interface can assert a signal referred to as“RMII CRS_DV”, or the carrier sense signal, to indicate that it is goingto send data to the Ethernet switch circuit 4020. Assertion of thissignal by one party allows the other communicating party to complete thetransmission of a current frame but not to start transmission of a nextframe. This arrangement is modified in the present embodiment so thatthe RMII CRS_DV signal can be asserted in one of two ways. Referring toFIG. 46, an OR gate combines two signals which can be asserted by theRMII device. One is a frame generator CRS_DV, which is a conventionalcarrier sense signal which is asserted only when a frame is to betransmitted, and the other is a signal referred to as RMII_lock.

RMII_lock is used as a “false” carrier sense signal to prevent theEthernet switch chip transmitting any data to the RMII device. It isused at times when the RMII device or further downstream devices are notready to receive any more data. The way in which RMII lock is assertedwill be described with reference to FIG. 46.

FIG. 46 is a state diagram illustrating states entered by the RMIIdevice 4130.

Starting from an idle state 4300, if more than 450 bytes have beenreceived from a MAC-DSD transceiver for onward transmission to theEthernet switch chip, then RMII_lock is asserted (a state 4310). This inturn asserts RMII CRS_DV. If the Ethernet switch chip is transmittingdata back to the RMII device at that point, it is allowed to finish itscurrent frame but not to start transmitting a new frame. However,because the Ethernet switch chip is running at 100 Mbit/s, higher thanthe data rate of all (or at least some in other embodiments) of theMAC-DSD transceivers, asserting RMII_lock when the input data reaches450 bytes still allows time for the Ethernet switch chip to finishsending an entire frame back to the RMII device.

Then, when the input memory reaches an occupancy greater than 486 bytes,the RMII device transmits the data to the Ethernet switch chip (a state4320). The threshold of 486 bytes is chosen with reference to acomparison of the two data rates of 5.6 Mbit/s and 100 Mbit/s, so thatby the time that the frame has been almost fully transmitted to theEthernet switch chip, the remainder of that frame should have arrived inthe DPRAM. The RMII interface then returns to the idle state.

As soon as the input memory is less than 450 bytes full or the outputmemory is less than 486 bytes full, and the device is in the idle state,then RMII_lock is de-asserted (state 4330).

On the receiving side, if data is received from the Ethernet switch chip(state 4340) and the reception has been completed, RMII_lock is asserted(state 4350) and the device returns to the idle state. As mentionedabove, RMII_lock is not de-asserted until the memory starts to empty ofthe data which has been received from the switch circuit.

The invention may be embodied in software, programmable hardware (e.g.FPGA, ASIC), hardware or a combination of these. In the case of asoftware component, the invention also includes a providing (e.g.storage, transmission) medium by which such software is provided.

Although illustrative embodiments of the invention have been describedin detail herein with reference to the accompanying drawings, it is tobe understood that the invention is not limited to those preciseembodiments, and that various changes and modifications can be effectedtherein by one skilled in the art without departing from the scope andspirit of the invention as defined by the appended claims.

1. A data communication system for communicating one or more payloadstreamed data signals and an auxiliary data signal, the auxiliary datasignal being organised as one or more data packets according to a datapacket protocol, each packet having a respective packet destinationaddress, the system comprising: (i) at least two data handling nodes, atransmitting one of said data handling nodes being arranged to transmitdata to a receiving one of said data handling nodes across a dataconnection link; (ii) a transmission data formatter associated with saidtransmitting node for formatting said data packets of said auxiliarydata signal into a streamed data signal format and for multiplexing saidpayload streamed data signals and said formatted auxiliary data signalinto a bitstream for transmission; (iii) a received data reformatterassociated with said receiving node for demultiplexing said inputstreamed data signals and said formatted auxiliary data signal and forreformatting said auxiliary data signal into packets according to saiddata packet protocol.
 2. Apparatus according to claim 1, comprising apacketizer, associated with said transmitting node, for organising saidauxiliary data signal into data packets.
 3. Apparatus according to claim1, in which said data packet protocol is an Ethernet packet protocol. 4.Apparatus according to claim 1, in which said data connection linkcomprises a physical layer of an Ethernet link.
 5. A system according toclaim 1, comprising a clock transmitter for transmitting a clock signal,associated with said payload streamed data signal, from saidtransmitting node to said receiving node.
 6. A system according to claim1, in which said one or more payload streamed data signals are audiosignals.
 7. A system according to claim 1, comprising an auxiliary datapacket router associated with said receiving node for routing packets ofsaid auxiliary data signal in accordance with said respective packetdestination address.
 8. A data router arranged to receive a data streamcontaining data packets, having associated destination indicators, viatwo or more input/output channels and to direct each packet to one ormore input/output channels in dependence on said respective destinationindicator, in which each input/output channel has an associated maximumdata rate, said router comprising: an Ethernet router; and a routinginterface associated with each input/output channel; said routinginterface and said Ethernet router being operable to communicate at adata rate higher than said maximum data rate associated with at leastsome of said individual input/output channels; said routing interfacebeing arranged to supply data packets received via said data streamassociated with that input/output channel to said Ethernet router insaid form of Ethernet data packets; said routing interface beingarranged to receive data packets to be output via said correspondinginput/output channel from said Ethernet router and to provide said datapackets as a data stream for output by that channel at a data rate nogreater than said channel's maximum data rate; and said routinginterface and said Ethernet router co-operating to selectively inhibitsaid transfer of data packets from said Ethernet router to said routinginterface in order to avoid exceeding that channel's maximum data rate.9. A router according to claim 8, in which said routing interface andsaid Ethernet router are arranged to communicate using a half-duplexprotocol in which transmission of a next data packet by one party isinhibited while another party asserts control of an inter-partycommunication.
 10. A router according to claim 9, in which said routinginterface is arranged to assert control of said inter-partycommunication during an arrival of an incoming data packet via thatinput/output channel.
 11. A router according to claim 10, in which saidrouting interface is arranged to assert control of said inter-partycommunication when a predetermined portion of said incoming data packethas been received via that input/output channel.
 12. A router accordingto claim 11, in which said predetermined portion is such as to allowtime to receive a remainder of that incoming data packet duringtransmission of that incoming data packet to said Ethernet router,taking into account said channel's maximum data rate and a data rate forcommunication between said routing interface and said Ethernet router,so as to allow a substantially uninterrupted onward transmission of saidincoming data packet.
 13. A router according to claim 9, in which saidrouting interface is arranged to assert control of said inter-partycommunication in response to receipt of a data packet from said Ethernetrouter, to inhibit receipt of a next data packet from said Ethernetrouter at least until an onward transmission of a newly received datapacket via said input/output channel has started.
 14. A router accordingto claim 9, in which said routing interface is arranged to assertcontrol of said inter-party communication by asserting a carrier sensesignal.
 15. A router according to claim 8, in which at least one of saidinput/output channels comprises at least one of a multiplexer formultiplexing said output data stream with a payload data stream fortransmission, and a demultiplexer for demultiplexing data packets froman input data stream comprising said data packets multiplexed with apayload data stream.
 16. A data transmitting node for transmitting oneor more payload streamed data signals and an auxiliary data signal to areceiving node, said auxiliary data signal being organised as one ormore data packets according to a data packet protocol, each packethaving a packet destination address, said transmitting node comprising:a transmission data formatter for formatting said packets of saidauxiliary data signal into a streamed data signal format and formultiplexing said payload streamed data signals and said formattedauxiliary data signal into a bitstream for transmission.
 17. A datareceiving node for receiving one or more payload streamed data signalsand an auxiliary data signal, said auxiliary data signal being organisedas one or more data packets according to a data packet protocol, eachpacket having a packet destination address, said packets of saidauxiliary data signal being formatted into a streamed data signal formatand multiplexed with said payload streamed data signals and saidformatted auxiliary data signal into a bitstream for transmission; saidreceiving node comprising: a received data reformatter fordemultiplexing said input streamed data signals and said formattedauxiliary data signal and for reformatting said auxiliary data signalinto packets according to said data packet protocol.
 18. A data signalcomprising a streamed payload data signal and an auxiliary data signalhaving data packets each with a packet destination address, sub-portionsof each packet of said auxiliary data signal being interspersed amongstdata bits of said payload streamed data signal.
 19. A method of datacommunication system for communicating one or more payload streamed datasignals and an auxiliary data signal, said auxiliary data signal beingorganised as one or more data packets according to a data packetprotocol, each packet having a packet destination address, said methodcomprising the steps of: (i) a transmitting node formatting said packetsof said auxiliary data signal into a streamed data signal format and formultiplexing said payload streamed data signals and said formattedauxiliary data signal into a bitstream for transmission; and (ii) areceiving node demultiplexing said input streamed data signals and saidformatted auxiliary data signal and for reformatting said auxiliary datasignal into packets according to said data packet protocol.
 20. A methodof routing a data stream containing data packets, having associateddestination indicators, received via two or more input/output channelsand directing each packet to one or more input/output channels independence upon a respective destination indicator, in which eachinput/output channel has an associated maximum data rate, using anEthernet data packet router and a routing interface associated with eachinput/output channel; said routing interface and said Ethernet routerbeing operable to communicate at a data rate higher than said maximumdata rate associated with at least some of said individual input/outputchannels; said method comprising the steps of: (i) said routinginterface supplying data packets received via said data streamassociated with that input/output channel to said Ethernet router asEthernet data packets; (ii) said routing interface receiving datapackets to be output via said corresponding input/output channel fromsaid Ethernet router and providing said data packets as a data streamfor output by that channel at a data rate no greater than said channel'smaximum data rate; and (iii) said routing interface and said Ethernetrouter co-operating to selectively inhibit said transfer of data packetsfrom said Ethernet router to said routing interface in order to avoidexceeding that channel's maximum data rate.
 21. A method of transmittingone or more payload streamed data signals and an auxiliary data signalto a receiving node, said auxiliary data signal being organised as oneor more data packets according to a data packet protocol, each packethaving a packet destination address, said method comprising the stepsof: (i) formatting said data packets of said auxiliary data signal intoa streamed data signal format; and (ii) multiplexing said payloadstreamed data signals and said formatted auxiliary data signal into abitstream for transmission.
 22. A method of receiving one or morepayload streamed data signals and an auxiliary data signal, saidauxiliary data signal being organised as one or more data packetsaccording to a data packet protocol, each packet having a packetdestination address, said packets of said auxiliary data signal beingformatted into a streamed data signal format and multiplexed with saidpayload streamed data signals and said formatted auxiliary data signalinto a bitstream for transmission; said method comprising the steps of:(i) demultiplexing said input streamed data signals and said formattedauxiliary data signal; and (ii) reformatting said auxiliary data signalinto packets according to said data packet protocol.
 23. Computersoftware comprising program code for carrying out a method according toclaim
 19. 24. A medium by which software according to claim 23 isprovided.
 25. A medium according to claim 24, said medium being atransmission medium.
 26. A medium according to claim 24, said mediumbeing a storage medium.
 27. Computer software comprising program codefor carrying out a method according to claim
 20. 28. A medium by whichsoftware according to claim 27 is provided.
 29. A medium according toclaim 28, said medium being a transmission medium.
 30. A mediumaccording to claim 28, said medium being a storage medium.
 31. Computersoftware comprising program code for carrying out a method according toclaim
 21. 32. A medium by which software according to claim 31 isprovided.
 33. A medium according to claim 32, said medium being atransmission medium.
 34. A medium according to claim 32, said mediumbeing a storage medium.
 35. Computer software comprising program codefor carrying out a method according to claim
 22. 36. A medium by whichsoftware according to claim 35 is provided.
 37. A medium according toclaim 36, said medium being a transmission medium.
 38. A mediumaccording to claim 36, said medium being a storage medium.